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A Professional Corporation 
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Costa Mesa, California 92626 

Telephone: (714)241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE, INC., 
Plaintiff, 

vs. 

NT OBJECTIVES, INC., et al., 
Defendants. 



CASE NO: 02CC15350 
Judge David H. Brickner 
Dept. C17 

DECLARATION OF DAN 
KUYKENDALL IN OPPOSITION TO 
OSC RE: PRELIMINARY 
INJUNCTION 

Date: October 25, 2002 

Time: 3:00 p.m. 

Dept: CI 7 



I, Dan Kuykendall, declare: 

1. The fects slated herein are of my own personal knowledge except forthose set forth 
onmfcnmtbn and belief, and as to any such facts, I have a basis forbeheving that they are true. 
If called upon to testify as a witness I could and would competently do so as set forth herein. 

KOLEIN THIS LITIGATION 

2. I am individually named as a defendant in this matter. 

3. I was employed by Plaintiff Foundstone, Inc. from August 2001 until July 1, 2002, 
as more fully set forthbelow. I was never an officer or director of that company. 
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1 1. Before I started on a new project at Foundstone, I was usually given a list of the 
desired features. I was not told what algorithms to use or how to make those features actually come 
into existence in the software. I was expected to figure out, based on my prior knowledge and 
experience, how to make the computer program do what was expected. 

12. One of the features on which I worked was the FoundScan web portal (aka 
Epenence). When I started I wrote the web interface to scan management in about three weeks. 
It was a good application, but there was nothing 1 did which was not the implementation of 
generally known computer programming practices. Moreover, the NTO toolkit does not have any 
web portaL 

13. Afterthat I helped with various tasks related to fixing and/or upgrading other parts 
of software programs at Foundstone. This included the creation of VulnTrak, a program which 
n-ftjnfr ros iecoids of vulnerabilities reported in client computer systems. It tookme about a month 
to write the VulnTrak computer program Once again, while it is a good implementation, there are 
no algorithms or methods iised in that computer program which, in my experience, are not akeady 
generally known to good programmers with experience in database programming, 

14. I was never asked to participate in the preparation of any application for a patent 
white Iwas at Foundstone. Ihave never been advised that I amnamed as the "inventor" on any 
patent application filed by Foundstone. 

FOUNDS TONE'S ALLEGED TRADE SECRETS 

15. I have read the Declaration of Stuart McClure submitted in support of this OSC re: 
Preliminary Injunction. From review of that document I am unable to determine any specific 
method, algorithmortechnique which is being referred to by Foundstone as a trade secret, with the 
possible exception of Foundscore. However, NTO isn't doing anything like Foundscore. 

16. As stated above,the workwbich I did while I was employed by Foundstone was good 
piDgramrmg, but the methods, techniques and algorithms which I used were the same as those I 
would expect would be used by any other excellent experienced programmer. 

17. The McClure declaration gives the impression that Foundstone might be claiming 
HIMLasatrade secret. The pages which display on the world wide web are mostly HTML. All 
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of the HTML techniques that I used at Foundstone were standard. No new ground was broken 
there. All of the HTML I have done at NTO is, likewise, standard programming techniques. 

18. Dmingthe entire time I was employed by Foundstone I never saw any documents, 
source code or other material with any "trade secret" or"secret" designation. 

TYFPIftTON TO T TTAVEFOIKDSTONE AND .TOTN NTO 

19. My comtortetotheFoundstone oflBce was too far. When I learned that my wife and 
I were going to have ababy I wanted to be closer to home so that I could assist my wife. I had told 
Foundstone, even during my initial interview, that I wanted to telecommute. However, I was only 
able to maintain the right to telecommute two days a week by threatening to quit. This made me 
unconibitabb wihrny position at Foundstone. Moreover, I found the pace of work at Foundstone 
tote frustrating. I would have little to do for an extended period of time while management created 
a document stating what features they wanted in the software. Then I would need to work 
frantically, for a couple of months , actually creating the program. 

20. I had m contact with JD, or anyone els e at NTO, regarding potential employment, 
until . after I left Foundstone. I gave my two week notice in mid-June. Our baby was bom on 
June 27, 2002 and my last day at Foundstone was July 1, 2002. 

21. Aflerlfctmy enpbyment at Foundstone I started to look for other employment. For 
a period of time I tried to work from my home but I decided I needed a more steady income. I 
contacted JD who I knew had started NTO after he left Foundstone. He told me that he was 
interested but that I would need to wait until he had enough money to fund a position for me. 

22. I subsequently joined NTO where I am presently the Senior Internet Software 
Engineer, 

23. We have,as a result of this litigation, been required to spend time meeting with our 
legal counsel Basedonthose discussions, and based on my discussions with the other employees 
ofNTO,andbased on my knowledge of computer programming and computer techniques, neither 
I,noranyotherpeison at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the busines s of NTO. 
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Steven Brower, State Bar #93568 
Brian Barrow, State Bar #177906 

STEPHAN, ORINGHER RICHMAN & THEODORA 

A Professional Corporation 
535 Anton Boulevard, Suite 800 
Costa Mesa, California 92626 
Telephone: (714) 241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONT^TNC., 
Plaintiff, 

vs. 

NT OBJECTIVES, INC., et al., 
Defendants. 



CASE NO: 02CC15350 
Judge David H. Brickner 
Dept. C17 

DECLARATION OF MICHAEL J. 
MORTON IN OPPOSITION TO OSC 
RE: PRELIMINARY INJUNCTION 

Date: October 25, 2002 

Time: 3:00 p:m. 

Dept: C17 



I, Michael J. Morton, declare: 

1 . The facts stated herein are of my own personal knowledge except for those set forth 
on information and belief, and as to any such facts, I have a basis for believing that they are true. 
If called upon to testify as a witness I could and would competently do so as set forth herein. 

ROLE IN THIS LITIGATION 

2. I am individually named as a defendant in this matter. 

3. I was employed by Plaintiff Foundstone, Inc. from January 2001 until June 2002, as 
more frilly set forth below. I was never an officer or director of that company. 
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BACKGROUND IN COMPUTERS 

4. I received a bachelors degree (Phi Beta Kappa) in Information and Computer Science 
from the University of California at Irvine in June, 1 994. 

5. I have been involved with computers since 1982. Prior to entering college I was fluent 
with several computer assembly languages (6502, Z-80, 8088, 6809) and with microcomputer 
architecture. I had written computer programs that dealt with: graphics and realtime video chip 
programming; hardware interrupts; an 80486 assembler; dabbled in TTL/CMOS logic design; 
designed several circuits. 

6. Since before college, and throughout my career, I have been evolving a program that 
does ray traced graphical rendering. This is a 3-D technique where you "draw" a ray of light with 
sufficient detail so that the final image has shadows, shading, perspective and reflections, all 
generated automatically. Part of the program includes the creation and implementation of a 
"description language," which is similar to creating a new computer programming language and a 
new computer program which understands that language and causes the computer to do what has 
been requested. 

7. I worked for Quarterdeck Corporation from June 1994 to October 1996 as a staff 
programmer. I learned about Windows programming and TCP/IP programming. During this 
employment I wrote a PPP layer to the Winsock product, which is a networking protocol related to 
Windows. 

8. I worked for Connect3 from October 1996 to April 1997 as a software engineer. I 
learned database programming including ODBC and SQL. 

9. I worked for Beckman (now Beckman/Coulter) from April, 1 997 to February, 2000 
as a senior software engineer. I did more database programming (ODBC, Oracle and SQL Server), 
more networking .(TCP/IP) and user interface Windows programming. I learned COM and ATL. 
All of this was done for a DNA Sequencer product referred to as the CEq-2000. 

10. I worked for HiHo.com from February 2000 to December 2000 as a senior software 
engineer. I learned HTML, DHTML, ASP, Winlnet, MTS and ActiveX, among others. The 
application we were working on was a distributed enterprise web application with a SQLServer 

D:\wpdocs\sbl02210.02 2 



DECLARATION OF MICHAEL J. MORTON IN OPPOSITION TO OSC RE: PI 

PAGE 61209 ' RCVD AT 7/112004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * 0NIS7469694 * CSID:9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:02pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P. 007 



F-609 



O 



i 

2 
3 
4 
S 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



database. This job, in my mind, represented a culmination of my prior experience with various 
computer technologies and added several new ones to my repetoire (all having to do with web 
programming.) 

EMPLOYMENT RY FOTJISHDSTONE 

11. I was happy with my employment at HfiHo. However, it was a casualty of the dot com 
decline. On the day that it became apparent to me that HiHo was dissolving, I received a telephone 
call from Bernard Lee, a recruiter, who pointed me to Foundstone. 

12. After a lengthy background check I began to work for Foundstone in mid-January 
2001 . 1 was a senior software engineer for the first 3 months then chief software engineer after that. 

13. Before I started on a new project at Foundstone, I was usually given a list of the 
desired features. I was not told what algorithms to use or how to make those features actually come 
into existence in the software. I was expected to figure out, based on my prior knowledge and 
experience, how to make the computer program do what was expected. 

14. "While employed by Foundstone I designed and implemented a reporting mechanism 
which I am informed and believe they are still using. Foundstone had previously obtained this 
fimctionality by using a software program from an outside vendor, but Foundstone wanted to save 
money. Substantial portions of the software I wrote for Foundstone were based upon work I had 
done while working for Beckman. All of the graphics techniques I used in the reporting mechanism 
were previously present in my raytracer software (see If 6). Although I showed the product to other 
people in the company and discussed features and functions with them, the design of the algorithms 
and the coding of the software was done solely by me, or by people working to implement my 
instructions. While the reporting mechanism is a good computer program, and while it provides the 
functionality to support that piece of Foundstone's business, I am unaware of any feature in that 
software package that is exclusive to Foundstone. Moreover, the Fire & Water software, to be 
released by NTO, does not include the reporting mechanism software which was created while I was 

at Foundstone. ; 

1 5 . While employed by Foundstone I designed and implemented the FASL (Foundstone 
Attack Scripting Language) that I am informed and believe they are also still using as part of their 
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vulnerability assessment. I had previous experience writing computer languages such as the 80486 
assembler which I had written before I worked at Foundstone. The graphics capabilities in that 
software were substantially based on my raytracer software (see % 6). Although I showed the 
product to other people in the company and discussed features and functions with them, the design 
of the algorithms and the coding of the software was done solely by me, or by people working to 
implement my instructions. While it is a good software package, and while it provides the 
functionality to support that piece of Foundstone's business, I am unaware of any feature in that 
software package that is exclusive to Foundstone. Moreover, the Fire & Water software, to be 
released by NTO, does not include anything like FASL. 

FOUNPSTONE'S ALLEGED TRADE SECRETS 

16. I have read the Declaration of Stuart McClure submitted in support ofthisOSC re: 
Preliminary Injunction. From review of that document I am unable to determine any specific 
method, algorithm or technique which is being referred to by Foundstone as a trade secret. 

17. . To the extent that I am generally familiar with the graphical techniques which exist 
in the Foundstone software, because they exist in software I worked on while I was at Foundstone, 
it is my testimony that all of the graphical techniques that Foundstone may be claiming as 
proprietary are documented in public domain materials. Specifically, to my recollection, they can 
all be found in a book called "Computer Graphics Principles and Practice" by Foley, VanDam, 
Feiner and Hughes. 

18. To the extent that I am generally familiar with the mathematical techniques which 
exist in the Foundstone software, because they exist in software 1 worked on while I was at 
Foundstone, it is my testimony that all of the mathematical techniques that Foundstone may be 
claiming as proprietary are documented in public domain materials, such as a standard linear algebra 
book. The cubic spline interpolation was done by copying code samples in a book called 
"Numerical Recipes" by William H. Press, Brian P: Flannery, Saul A Teukolsky and William T. 
Vetterling. 

1 9. The McClure declaration gives the impression that Foundstone might be claiming 
HTML as a trade secret The pages which display on the world wide web are mostly HTML. All 
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of the HTML techniques that I used at Foundstone were standard. No new ground was broken there. 
All of the HTML I have done at NTO is, likewise, standard programming techniques. 

DECISION TO LEAVE FOUNDSTONE AND JOIN NTO 

20. ID Glaser and I became friends while we were both working at Foundstone. Prior to 
giving notice at Foundstone I asked JD whether I could work for his company. He advised me that 
under his Employment Agreement with Foundstone he could not have any such discussion with me 
while I was working for Foundstone. 

21 . Therefore, I gave my two week notice to Foundstone. My last day with Foundstone 
was June 28, 2002. 

22. I subsequently applied for a job with NTO. I am presently the Senior Software 
Engineer for NTO. 

23. We have, as a result of this litigation, been required to spend time meeting with our 
legal counsel. Based on those discussions, and based on my discussions with the other employees 
of NTO, and based on my knowledge of computer programming and computer techniques, neither 
I, nor any other person at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 

I declare, under penalty ofperjury, that the foregoing is true and correct and that this 
declaration is executed on October 23, 2002, under the laws of the State of California. 
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Steven Brower, State Bar #93568 
Brian Barrow, State Bar #177906 

STEPHAN, OR1NGHER RICHMAN & THEODORA 

A Professional Corporation 
535 Anton Boulevard, Suite 800 
Costa Mesa; California 92626 
Telephone: (714) 241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE, INC., 
Plaintiff, 

vs. 

NT OBJECTIVES, INC., et al., 
Defendants. 



CASE NO: 02CC15350 
Judge David H. Brickner 
Dept. C17 

DECLARATION OF ERIK CASO IN 
OPPOSITION TO OSC RE: 
PRELIMINARY INJUNCTION 

Date: October 25, 2002 

Time: 3:00 p.m. 

Dept: C17 



I, Erik Caso, declare: 

1 . The iacts stated herein are of my own personal knowledge except for those set forth 
on information and belief, and as to any such facts, I have a basis for believing that they are true. 
If called upon to testify as a witness I could and would competently do so as set forth herein. 

ROLE IN THIS LITIGATION 

2. I am individually named as a defendant in this matter. 

3. I was employed by Plaintiff Foundstone, Inc. from May 2001 until June 2002, as more 
fully set forth below. I was never an officer or director of that company. 
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BACKGROUND IN COMPU TER BUSINESS 

4. I obtained my bachelors degree in Business from California Polytechnic State 
University, San Luis Obisbo in June, 1997. My coursework included web design/authoring and 
using complex modeling software to create statistical forecasting models. 

5. From April 1998 to March 2000, 1 was employed by The Boeing Company as a 
Business Analyst, using software for financial modeling of return on investment and other business 
planning. 

6. From March 2000 to February 2001, 1 was employed by Epoch Internet as a Product 
Manager. I designed software based products for a large Internet Service Provider (ISP) including 
email system and real-time provisioning systems for an online portal. 

EMPLOYME NT BY FOT 1NDSTONE 

7. A colleague of mine from a prior job referred me to Foundstone: I liked the idea of 
working for a small company which was known for doing good work. 

8. I began to work for Foundstone on or about May 1 5j, 2001 . My title was Product 
Manager. My supervisor was Dave Cole, although I primarily reported to Stuart McClure. 

9. I was involved in the design and execution of the FoundScan technology. That is, I 
worked on deciding what features should be included in the Foundscan software in order to provide 
the features which Foundstone clients either requested or which Foundstone believed would increase 
customer demand for Foundstone services. I was also responsible for Foundstone's beta testing 
software program, sales assistance, development of marketing related materials, ensuring Quality 
Assurance for software, and overall management of FoundScan related objectives. . 

10. My job responsibilities at Foundstone did not include any computer programming. 
Although I have worked with computer companies I have not actually done any computer 
programming. 

11. I was never asked to participate in the preparation of any application for a patent while 
I was at Foundstone. I have never been advised that I am named as the "inventor" on any patent 
application filed by Foundstone. 
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12, As the person responsible for the overall business strategy of NTO I have been asked 
to explain the difference between Foundstone. and NTO. Attached hereto as Exhibit "A/ and 
incorporated herein by reference, is a document I prepared that provides a detailed description of 
the features and functions which will be included in the "Fire & Water" tools which NTO intends 
to distribute. Attached hereto as Exhibit "B," and incorporated herein by reference, is a document 
I prepared that provides my description of Foundscan, the software package utilized by plaintiff. 
As will be readily apparent, it is materially different from anything being done by the Tire & 
Water" tool kit Attached hereto as Exhibit "C," and incorporated herein by reference, is a 
comparison chart which I prepared showing features of FoundScan in comparison with those in the 
Tire & Water" package. That document also shows features that are present in other software 
programs produced by entities who are not parties to this litigation, 

FOUNDSTONE'S ALLEGED TRADE SECRETS 

13. I have read the Declaration of Stuart McClure submitted in support of this OSC re: 
Preliminary Injunction. From review of that document I am unable to determine any specific 
method, algorithm or technique which is being referred to by Foundstone as a trade secret 

14. Although they are not clearly identified by the McClure Declaration, there are two 
databases which I believe might constitute the type of proprietary information to which Stuart 
McClure intends to refer. One of those might be referred to as the OS Fingerprint file* This would 
be the collection of information which is used by Foundstone to do Operating System identification. 
While I am informed that the technique of OS identification is not proprietary to Foundstone, their 
database of this information is extensive and might normally qualify as proprietary* The second 
would be the database of vulnerabilities. I am told that such a listing is actually a matter of public 
knowledge, but I believe this is something to which Stuart McClure was referring in this 
Declaration. 

15, These two databases (OS Fingerprint and Vulnerabilities) are part of the FoundScan 

suite of security programs. During the time that I was employed by Foundstone, the OS Fingerprint 

database was maintained in an "unencrypted" form. That is, anyone who had access to the computer 

program could read and/or print the entire contents of the OS Fingerprint database. 
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16. As a regular part of my job at Foundstone, 1 was involved in sending "evaluation 
copies" of our software to the trade press so that they would review our products and provide us with 
coverage. When dealing with the press there are never any confidentiality agreements requested or 
obtained because die very purpose of sending the copies to the press is so that they will make public 
comments about your services and software. 

17. I specifically recall that copies of the Foundstone software (and, therefore, fill] ability 
to view and/or print the contents of the databases) was provided to: John Taschek and Jim Rapoza 
of eWeek Labs; Andrew Conry-Murray of Network Magazine; Jane Parkhouse of SC Magazine; 
Mandy Andress of InforWorld; and, Konstantinos Karagiannis of PC Magazine. Each of those 
people, and their publications, had full and unfettered ability to view and/or print the entire contents 
of the Foundstone OS Fingerprint database. 

1 8. Notwithstanding the potential public disclosure of this database, I want to be sure it 
is clear that NTO is not including any OS Identification in the "Fire & Water" package. Moreover, 
NTO does not have any copy of the Foundscan OS Identification database. 

DECISION TO LEAVE FOUNDSTONE AND .TOTN NTO 

19. I left Foundstone because of its lack of interest in employee satisfaction and poor 
management. When I advised Dave Cole and Stuart McClure that I was quitting they asked if there 
was any job at the company, which they could give me, which would make me stay. When I turned 
them down they told me that I could return to Foundstone at any time in the future. 

20. I began to look for a new job about a month before I left Foundstone. This was about 
a month after JD Glaser left Foundstone. I contacted him to see what he was doing since we had 
been friends while he was working for Foundstone. As a business person, rather than a technical 
person, I told him that I had some ideas about how to structure a successful organization. 

21. I subsequently joined NTO where I am presently the Director, Product Strategy. My 
role is to develop and implement our overall product and business strategy. 

22 . We have, as a result of this litigation, been required to spend time meeting with our 
legal counsel. Based on those discussions, and based on my discussions with the other employees 
of NTO, and based on my knowledge of computer prograniming and computer techniques, neither 
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I, nor any other person at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 

I declare, under penalty of perjury, that the foregoing is true and correct and that this 
declaration is executed on October 23, 2002, under the lawy®f the State of California. 

ErikCasJ 
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What is FoundScan? 

FoundScan is an advanced, network based ^Vulnerability Management 
Technology"' .that is designed to identify all network based assets, 
their corresponding vulnerabilities, and provide a comprehensive system 
in which to manage the elimination of those vulnerabilities* FoundScan 
is deployed in a single machine or multi-machine architecture , and may 
he run as a distributed system where various servers are in separate, 
locations. Deployment requires a FoundScan Consultant to be- onsite 
performing the installation and setup,, ranging from one to two days 
work- All FoundScan data is kept in a Microsoft SQI# database, and 
requires the installation of this and other third party software in 
• order to operate (the web portal requires Microsoft IIS to operate) > 
All machines in a FoundScan system must be properly configured and 
maintained in order to operate properly; there is extensive work that 
must be performed and maintained in order to ensure proper 
communication between the machines in a FoundScan system or they will 
fail to work entirely . 

Components and features of the . ""FoundScan Enterprise Vulnerability 
Management System": 

• Discovery Engine - identifies, enumerates and classifies each 
host on a network. Classification can include the operating 
system, open ports, banners, hostname, and even device type (i.e. 
routers, firewalls, servers and 802.11 wireless devices*} 

• Vulnerability Engine - includes- the vulnerability checks that are 
performed by FoundScan and a database of all check related 
information (i.e. descriptions, recommendations, CVE numbers and 
more) . FoundScan currently checks for more than 530 
vulnerabilities, and grows in number on a weekly basis. The 
checks are preformed using a scripting language developed in- 
house, called FASL : (FoundScan Attack scripting Language) . 

• web Portal - a comprehensive, interactive web portal that allows 
for complete management of the FoundScan features. Governed by 
rule-based access, each user has an account with discreet 
permissions as to how they may interact with the system; account 
types include Administrator, Full and View Users. The portal 
allows for account ere at ion/ management, viewing of scan reports, 
data search functions, and remediation management control. 

• Remediation Engine - embedded in the Web Portal, the remediation 
management component, dubbed " VulnTrak, allows for work flow 
management of vulnerabilities discovered by FoundScan. Akin to a 
trouble ticket system, VulnTrak allows for an Administrator to 
assign vulnerabilities to users, who are then alerted to the 
ticket and must go and fix the security issue. Once completed, 
they may verify and close the ticket, returning it to the 
Administrator for archiving. r 

• Numerous ancillary features, including email alerting, iDefense 
security reports (provided by a third party), and much more. 

FoundScan is designed, marketed, and sold as an enterprise security 
solution used to identify vulnerabilities in a corporate network. It 
■ is not currently designed to handle numerous, . non- recur ring" projects 
related to network management, "as the investment in such work is much 
greater than the resulting- output (i.e. an administrator that needs to 
create and run numerous 'discreet network tests would not use FoundScan 
due to the amount of time it takes to log into the system, create the 
proper scan(s), run them, log into a web portal account, select the 
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scan, view the information and than act.) FoundScan is designed to run 
as a network service, where an administrator creates recurring 
assessment scans, or jobs, which are run on a schedule* These jobs are 
then reviewed on a recurring basis and used to determine the security 
posture of an organization or network. Each 30b is configured to be 
automatically distributed to unlimited individuals, based on whether 
they have access to the job or not. FoundScan may be purchased as a 
licensed technology or a managed service. 
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Feature comparison foir . Fire a Water and Founds can 

The above general descriptions of each product attempt: to clearly 
indicate the intended design of each product . with that considered, 
there are several features . and capabilities common to both 
technologies , as well as many Other competing technologies offered by 
other software vendors. While these features/capabilities may be 
shared, it is important to note that in not a single case is there a 
shared feature that is a proprietary technology of either company; 
various implementations and variations of these features/capabilities 
may be readily found in numerous software products and have been 
discussed and available in public forums long before the founding of 
either Foundstona {founded late 1999) or NT OBJECTives (founded mid- 
1997). 

For a feature breakdown please see the Fire & Water - FoundScan Feature 
Comparison document. 
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FEATURE 



FIRE&WATER FOUNPSCAN 



Gsnoral Assessment 








TCP port scanning 


YES 


YES 


nmap. superscan, and numerous others 


UDP oort scanning 


NO 


YES' 


nmap, Supers C3n, and numerous ethers 


finnnnr tirabbfrta 


YES 


YES 


nmap, supers can, and numerous others 


^RrvinA ftrtlJIflAratron 

•Jul V l^sTJ VI H-MI po> CI UU1 1 


NO 


YES 


nmap 


rinnrnfirtn ftSmtnm IrinnKfir^iHnri 


NO 


YES 


- runan xoroba oueso 


rlDQlJiuFIIcJ lObUILIUun 




T CO 


iHi\a\J, iioivuiMjp, I lull Iukjud UUialiS 


IflUID +Tnr*onM itlnn 
\\-i\v\* U a uc 1 LnJ U 1 1 y 




T CO 




Tf'D (nporniitlpwi 

1 t*r* irHCisiuiiurig 


Kin 


ICS 






MA 


1 CO 


rhuanrvc 1 AM Mnn^hnt 




MA 

nu 


T u-S> 


im, riis2AU£i| LrtM rndponoir innow, many iron 


Database detection 


NO 


YES 


AppDatective, ISS 


Wireless device detection 


NO 


YES 


ISS, nassus 


vjorrorai ueionso 








J5>Arl Twer 


YES 




UKLOcan 


Attack signature recognitior^based web server defense 


YES 




Snort 


Vulnerability Checking 








Network, level checks. 


NO 


YE5 


nessus, ISS, cybercop, whisker, retina «• more 


Operating system checks 


NO 


YES 


neBSU3. ISS, cybercop, many more 


Remote windows registry checks 


NO 


YES 


nessus. ISS, cybercop. many more 


Web server checks 


YES 


YES 


nessus, ISS, cybercop, whisker, retina 


[Web] application checks • 


NO 


YES 


owasp toots, Wharsenal, whl3ker, retina 


Wireless device checks 


NO 


YES 1 


nessus, )SS 


Vulnerability risk rating 


NO 


YES 


nessus. CyberCop. ISS, Shadow, many more 


Custom Scripting language for vulnerability checks 


NO 


YES 


nessus (nasi) 


Interpreter for. parsing and executing the scripting language 


NO 


YES 


nessus (nasi) 


Data Storage 








Enterprise database usage (MS SQL) 


NO 


YES 




Date Encryption 


NO 


YES 




. Segregation of data by customer 


NO 


YES 




Segregation of data by user account 


NO 


YES 





Online Data Presentation and Management 

Wob based portal with access control NO 

Online account management NO 

Integrated remediation managementfworkflow system (VulnTrak) NO 

Query based data searching (database) NO 

Scan scheduler NO 

Automated scan instantiation (starts scans) NO 

Automated/configurable web based alerting NO 

Automated/configurable smart Alerting NO 

Multi-tier account creation tor granular access control NO 

Interface for complete system management NO 

Secure communication over SSL (encrypted traffic) NO 

Includes third party security intelligence reports NO 

Reporting 

Summary level reporting YES 

Detailed reporting on a feature basis NO 

Network mapping - host level YES 

Network mapping - firewall level NO 

Network mapping - router level NO 

Network mapping - dual homed devices NO 

Data trending (plot historic data points on graph) YES 

Miscellaneous 

Runs only from the command line (Le. the "C:\>* prompt) * YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 
YES 



YES 
YES 
YES 
YES 
YES 
YES 
YES 



NO 



EXISTING TOOLS DOING SAME THING 



Retina, ISS, many more 
Retina, ISS, many mom 

Retina 

ISS. Retina, CyberCop, Shadow, many more 



ISS, CyberCop. nessus, many other 
nossue.ISS 

cheeps, CyberCop, LAN MapShot, InFkw. many 
cheops, LAN MapShot, InFlow, many more 
cneops, LAN MapShot, InFlow, merry more * 
cheops, LAN MapShot, Inflow, many more 



nessus. nmap 



PAGE 20/209 * RCVD AT 711(2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DNIS:7469694 * CSID:9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:05pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-7Q2 P 021/104 F- 



o 



Runs as a network service 

Distributed system* multiple servers geographically based 
Able to run numerous simultaneous scans 
Security scoring to indicate risk posture 
Available as a managed service 
Available as software 

No Instigation required. Just copy files to desired directory 
Requires a trained consultant for configuration and Installation 
Requires System management to ensure operation 
Auto-update feature to auto download system updates 
Requires third party enterprise software to operate 

Marketing & Sales 
Target market 



Price 



NO. 
NO 
NO 
NO 
NO 
YES 
YES 
NO 
NO 
NO 
NO 



Security and 
systems - 
administration 
professionals 
looWng for 
lightweight 
tools to perform 
discrete tasks 
(such as finding 
web servers). 



Free, or single 
user license 
may be 
purchased for 
$150. 



YES 
YES 
YES 
YES 
YES 
YES 
NO 
YES 
YES 
YES 
YES 



Large 

enterprises 

that require 

comprehensJv 

e "Vulnerability 

management* 

solution. 



Published 
pricing begins 
at $30,000, 
Individual 
sales generally 
run $100,000- 
700,000 for 
technology 
licensing. 



ISS 

rss 

ISS, CyberCop, many more 

ISS 
All . 
nmap 

ISS, CyberCop. Retina, many more 



*NOTE - This feature list comprises all known FoundScan and Fire & Water features 
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Steven Brower, State Bar #93568 

Brian Barrow, State Bar #177906 

STEPHAN, ORINGHER RICHMAN & THEODORA 

A Professional Corporation 

535 Anton Boulevard, Suite 800 

Costa Mesa, California 92626 

Telephone: (714)241-0420 

Attorneys for Defendants 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE, INC., 
Plaintiff, 

vs. 

NT OBJECTTVES, INC., et al. 
Defendants. 



CASE NO: 02CC 15350 
Judge David H. Brickner 
Dept. CI 7 

DECLARATION OF JASSEN D. 
GLASER IN OPPOSITION TO OSC RE: 
PRELIMINARY INJUNCTION 

Date: October 25, 2002 

Time: 3:00 p.m. 

Dept: C17 



I, Jassen D. Glaser, declare: 

1. I am a defendant in this action. The facts stated herein are of my own personal 
Knowledge except for those set forth on information and belief, and as to any such'facts, I have a 
basis for believing that they are true. If called upon to testify as a witness I could and would 
competently do so as set forth herein. 

ROLE IN THIS LITIGATION 

2. I am individually named as a defendant in this matter. I am also the president, director 
25 1 and majority shareholder of defendant NT Objectives, Inc. ("NTO"). 



26 
27 
28 
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3. I was previously employed by Plaintiff Foundstone, Inc. for approximately two years 
as more fully outlined below. I was never an officer or director of Foundstone. That is, while my 
title was "Director of Engineering" I was never a director in the legal sense of service on the Board 
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1 NTO. I told him that I wanted to develop one of the products which I had previously sold to 

2 Foundstone, VisualLast, which Foundstone was obligated to return to me under oral agreement, I 

3 even asked him to invest $250,000 in NTO. In fact, I have several emails from Jeanne Miller- 

4 Romero, the inhouse legal counsel at Foundstone, as late as 3 months after I resigned from 

5 Foundstone, saying that she is working on getting an agreement approved to return that software to 

6 me. However, I ultimately realized that Foundstone was not going to proceed with the oral 

7 agreement. 

8 FOUNDSTONE *S ALLEGED TRADE SECRETS 

9 26. I have read the Declaration of Stuart McClure submitted in support of this OSC re; 

10 I Preliminary Injunction, From review of that document I am, unable to determine any specific 

11 method, algorithm or technique which is being referred to by Foundstone as a trade secret 

12 27. As stated above, the work which I did while I was employed by Foundstone was good 

13 programming, but the methods, techniques and algorithms which I used were the same as those I 

14 would expect would be used by any other excellent experienced programmer. 

15 28. The McClure declaration tries to give the impression that there are real technology 

16 secrets at Foundstone. I would, almost without exception, disagree, as more fully set forth below. 

17 29 ♦ As differentiated from the technical area, I would agree that Foundstone probably has 

18 legitimate trade secrets regarding certain aspects of their customer relationships, their pricing 

19 strategy, and their financial affairs. However, those items are simply not implicated here. We are 

20 offering a different product and/or service to a different market. Foundstone's minimum service 

21 packages are over $30,000 and it was my impression that they really were not interested in packages 

22 of less than $50,000. NTO's 'Tire & Water" package is free to individuals and $125 for 

23 organizations. It is not just a matter of degree. We do not offer a service which replaces the service 

24 H offered by Foundstone. While we would be willing to do business with the same companies which 

25 | are customers of Foundstone, any resulting business we received would be in addition to* not instead 

26 of, any service which those companies were obtaining from Foundstone. 

27 1 30. A simple example might help to explain the material difference between the business 

28 1 of Foundstone and the business of NTO. The tools which NTO intends to provide as part of Tire & 
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Water" are solely for stand-along use. In contrast, none of Foundscan can be used without 
connecting the software to an Enterprise SQL database (a separate special purpose computer with 
special purpose software). 

31. Foundstone does have real competitors. Those companies would include Qualys, 
Guardent and Vigilante. Some of those companies are much larger than Foundstone and claim to 
offer many more capabilities than Foundstone, Those companies already claim to have the 
technology and the ability to do what is done by Foundstone. To the extent they do not have such 
capabilities it is because they have not undertaken the expense or the effort to write the software, 
but it is D£t because there are "secrets" that they don't know or can't obtain from public sources, 

32. We have, as a result of this litigation, been required to spend time meeting with our 
| legal counsel. Based on those discussions, and based on my discussions with the other employees 

of NTO, and based on my knowledge of computer programming and computer techniques, neither 
I, nor any other person at NTO, is utilizing anything which I understand to constitute a trade secret 
of Foundstone in the furtherance of the business of NTO. 

33 . For every technology employed by Foundstone I can find and reference a pre-existing 
public source for that technology. This would specifically include, but not be limited to, clear 
instruction on how to do network topology maps. To the best of my knowledge, during the time I 
was employed by Foundstone we didn't invent any new algorithms or technological advancements. 

DECISION TO LEAVE F OUNDSTONE 

34. After almost two years at Foundstone I realized that I did not have any real future or 
potential for advancement at Foundstone. I decided to resume working for myself at NTO. I 
advised Stuart McClure that I would be resigning. My last day at Foundstone was May 3, 2002. 
In feet, on that date, I *gave w a brand new software tool to Foundstone as a departing present, I am 
informed and believe that the software tool has been utilized by Foundstone to enhance its 
marketing efforts and is currently downloadable from their website. 

35. I am aware that under my employment agreement with Foundstone I am not allowed 
to solicit any Foundstone employee to work for NTO. Whether or not such term is legally valid I 
have fully complied with the spirit of the requirement. I have never contacted any employee of 

D:topdocs\5bID2 110.02 7 

DECLARATION OF JASSEN 0 GLASER IN OPPOSITION TO OSC RE: PI 

RCVD AT 711/2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DNIS:7469694 ■ CSID:9497609502 ■ DURATION (mm-ss):5746 



Jun-30-2004 09:07pm Frcm-KNOBBE MARTENS OLSON BEAR 

o 



949 7609502 



T-702 P 025/104 F-609 



1 

2 
3 
4 
5 
6 
7 



o 



10 

11 

12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



Foundstone to suggest that they work for me and/or NTO. However* our software development 
group was relatively small and I was friends with many people at the company, When people who 
are employees of Foundstone have contacted me to find out whether they can work for NTO I have 
reminded them of the non-solicitation clause and I have told them that I can't make any agreements 
with them while they are employees of Foundstone. 

ADDITIONAL ITEMS OF INFORMATION 

36. The Declaration of Stuart McClure fl[ 30-32) refers to a presentation which I made at 
8 1 the Black Hat conference on July 29, 2002. It is phrased in a strange way because Mr T McClure was 
9 not actually there during my presentation. He is just reporting what he was told by someone else. 

Significantly s the presentations, including the one I gave with Michael Morton, are videotaped. 
After this litigation started we ordered a videotape of the presentation which our counsel will make 
available for review, by the Court, upon request. Within the past week I have reviewed everything 
which was said by me, and by Mr. Morton, on that videotape. There is nothing which we said which 
reveals or refers to any trade secrets of Foundstone. 

37. In the interest of clarity, I will address one specific hearsay statement by Mr, McClure. 
He says in his Declaration fl[ 3 1 ) that one of the functions demonstrated at the Black Hat conference, 
which "mimicked the proprietary functions" of FoundScan was "determining and graphically 
mapping a computer network in a manner nearly identical to FoundScan. 1 ' Attached hereto as 
Exhibit "D" is the graphical mapping of a computer network as performed by FoundScan. This 
example is intentionally publicly disclosed by FoundStone on their website. Attached hereto as 
Exhibit "E" is the version which is posted on the NTO website and which was shown at the Black 
Hat conference which Mr. McClure describes. 

38. In the Declaration of Stuart McClure Cff 32) he says that it would have been impossible 
for us to create the Fire & Water toolkit in three months. I would note the following. First, while 
we announced the toolkit at that time, it clearly wasn't finished. It was more than two months later 
that we first said we would be ready to make that tool available. Second, while I was at Foundscan 
I saw a PowerPoint presentation, done by Mr. McClure, which showed that my development teams 
were capable of preparing computer code at impressive rates, not because of any technology at 
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Foundscan, but because of my abilities and those of my staff. Third, as set forth in the declaration 
of Michael Morton, the various graphical mapping capabilities which exist in the Foundscan 
software are almost exclusively the byproduct of Mr. Morton's prior work on his rayscan project 
or are otherwise disclosed in the books to which he references. Fourth, had Mr. McClure been 
present at the presentation he is describing to the Court he would have known that the graphical 
displays which NTO intends to distribute do net mimick the proprietary functions of Foundscan. 

. 39, The Declaration of Stuart McClure makes reference to Operating System 
Identification. We have elected not to provide the court with a mountain of paper showing how 
much of the technology, generally referred to by Foundstone, is in the public domain. However, in 
the interest of clarity, attached hereto as Exhibit "F" is Version 2.5 of the paper M ICMP Usage in 
Scanning" by Ofir Arkin, the founder of the Sys-Security Group. Ofir Arkin does not have any 
affiliation with Foundstone or with NTO. This paper can be obtained as a free download, without 
any registration, payment or agreement to any conditions. This document discloses, to those who 
take the time to understand the document, how to do what is referred to by Mr. McClure as OS 
Identification. I know that this document forms the basis for the OS Identification in the FoundScan 
product because various versions of this document were used by my development team in order to 
implement OS Identification at Foundstone. 

40. Further, attached hereto as Exhibit u G n is the home page from www.sys-security.com, 
the organization operated by Ofir Arkin. At the bottom of the page it refers to Xprobe2 "an active 
operating system fingerprinting tool with a different approach to operating system fingerprinting. 
Xprobe2 rely on fuzzy signature matching, probablistic guesses, multiple matches simultaneously, 
and a signature database ." It also indicates that you can download the source Cfldp, for free, from 
this site. We are not arguing that this is the exact same thing as what Foundstone is offering. In 
fact, in some ways it may even be more sophisticated than Foundstone. Our concern is that when 
Foundstone claims to "own" OS Identification, or any of their other alleged trade secrets, without 
defining what they have which is different or special (i.e. - which might qualify as a trade secret), 
we can't show that the specific item: a) is not, in fact, a secret; or b) is not, in fact, used by NTO. 
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41. While we reserve the right to use any non-proprietary technology in the future, 
including OS Identification, it should be clearly noted that the "Fire & Water" package does not 
include any OS identification and has never been intended to include such capability. 

I declare, under penalty of perjury, that the foregoing is true and correct and that this 
declaration is executed on October 23, 2002, under the laws of the State of California. 
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Steven Brower (State Bar No. 93568) 

Brian P. Barrow (State Bar No. 177906) 

STEPHAN, ORJNGHER, RICHMAN & THEODORA, P.C. 

535 Anton Boulevard, Suite 800 ' 

Costa Mesa, California 92626-1902 

Telephone (714) 241-0420 

Telecopier (714) 24T0622 

Attorneys for Defendants 
NT OBJECTIVES, INC., J.D. GLASSER, 
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SUPERIOR COURT OF THE STATE OF CALIFORNIA 
FOR THE COUNTY OF ORANGE 



FOUNDSTONE, INC., a Delaware 
corporation 
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corporation; LD. GLASER, an individual; 
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CASO, an individual; DAN 
KUYKEND ALL, an individual; and DOES 
1 through 50, Inclusive. 
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Case No. 02CC15350 

ASSIGNED FOR ALL PURPOSES TO: 
HONORABLE DAVID H. BRICKNER 
DEPT: C17 

MEMORANDUM OF POINTS AND 
AUTHORITIES IN SUPPORT OF 
DEFENDANTS* OPPOSITION TO 
PLAINTIFF'S OSC RE: 
PRELIMINARY INJUNCTION 

HEARING DATE: October 25, 2002 
TIME: 3:00 p.m. 
DEPT: C17 
TRIAL DATE: None 

COMPLAINT FILED: October 2, 2002 



MEMORANDUM OF POTNTS AND AUTHORITIES 
L INTRODUCTION 

Plaintiff Foundstone, Inc. seeks to enjoin its former employees from releasing "Fire & 
Water Toolkit," a computer software product that Foundstone has never seen, but which 
allegedly incorporates misappropriated trade secrets. Foundstone fails to identify the supposedly 
stolen trade secrets or specify how they are supposedly being used in defendants' product, 
instead relying on an allegation that defendants could only have developed their product by 
virtue of their prior employment at Foundstone. 
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allegation its "algorithms, methods* and databases" are trade secrets thus does not describe 
which, if any, of the components of "Fire and Water Toolkit" were supposedly misappropriated 
from Foundstone, Without such descriptive information, Foundstone fails to demonstrate any 
likelihood of success on the merits or make any showing of relative interim harm. 

3. FoundstoDe Also Refuses To Provide Further Specificity Of Its Alleged 
Trade Secrets As Required By the Discovery Act, 
Code of Civil Procedure section 2019, subdivision (d) 3 states the following with regard 
to identification of trade secrets prior commencing discovery: 

In any action alleging the misappropriation of a trade secret . . . , before 
commencing discovery relating to the trade secret, the party alleging the 
misappropriation shall identify the trade secret with reasonable particularity 
subject to any orders that may be. appropriate under [the Uniform Trade Secret 
Act], 

Defendants have repeatedly asked Foundstone for such an identification, specifically 
explaining that Foundstone's pleadings contain an insufficient description of the alleged trade 
secrets. Tellingly, Foundstone has so far refused to provide defendants with the requested 
specificity, despite previously seeking leave to commence the discovery process. 

D. Foundstone's "Software, Methods, and Algorithms" Are Not Protectible 
Trade Secrets. 

Even if the generic "software, methods, and algorithms*' is considered a sufficient 
description of a trade secret, Foundstone nevertheless fails to provide evidence demonstrating 
that such material is entitled to trade secret protection, Foundstone thus fails to show that its 
claimed "software, methods, and algorithms" are actually trade secrets. 

cc The test for trade secrets is whether the matter sought to be protected is information (1) 
which is valuable because it is unknown to others and (2) which the owner has attempted to keep 
secret." (Schlage Lock Company v. Whyte (2002) 101 CalApp.4th 1443, 1453, citing Abba 
Rubber Co, v. Seaquist (1991) 235 CalApp3d 1, 18.) Foundstone offers no evidence satisfying 
either of these requirements. 
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Foundstone's Alleged Trade Secrete and Software Products Are Based 
on Information Available In the Public Domain. 

The United States Supreme Court has stated that information that is public knowledge or 
that is generally known in an industry cannot be a trade secret. (Ruckelshaus v. Monsanto Co. 
(1984) 467 U.S. 986, 1002.) 

As shown in the Declarations submitted in Opposition, Foundstone did not actually invent 
anything. To the extent that defendants are able to identify alleged trade secrets the Declarations 
show that such materials were originally created by sources outside of Foundstone, are known 
to those who are experienced in the industry, or have been deliberately disclosed to the public 
by Foundstone. 

2> Foundstone Disclosed Any Tirade Secrets Contained In Its Software 
When It Provided Unprotected Marketing Versions to the Press, 

Foundstone cannot validly claim that its various databases upon which FoundScan 
operates have been the subject of efforts to prevent the loss of secrecy. As explained in the 
declaration of defendant Erik Caso, Foundstone repeatedly provided members of the press with 
copies of its software products that were vulnerable to disclosure. Foundstone never insisted that 
the members of the press to whom the software was delivered execute nondisclosure agreements 
or otherwise promise not to publicize its alleged trade secrets. As such, members of the press 
who received the software were free to, even encouraged to, view the very components of the 
software (i.e. databases, etc) that Foundstone now contends are trade secrets they have attempted 
to keep confidential. Foundstone's own acts of disclosing information to outsiders demonstrates 
that the alleged trade secrets no longer enjoy the secrecy that Foundstone claims in this lawsuit. 

E. Foundstone Has No Evidence of any Actual or Threatened Misappropriation 
of "Software, Methods, and Algorithms" 

This court may only enjoin "actual or threatened misappropriation" of a trade secret 
(Civ. Code, § 3426.1, subd. (a).) "Misappropriation" is defined in this context as improper 
acquisition of a trade secret or its nonconsensual use or disclosure. (Civ. Code, § 3426-1 , subd. 
(b).) Foundstone is therefore burdened with making a showing that defendants are either 

10 
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onty actual "tacts" they have presented to the court 
These are my opinions and while I believe everything I am 
staling to be true, this Is not a legal rebuttal* I will be posting 
all our legal responces as they become avaH&Ie, 

First lets took at what the law considers a Trade Secret: 
A good exp lanation basldy says that "A trade secret Is any 
Information that allows you to make money because It Is not 
generally known". Since hacker techniques are generally known 
and published on several websites, as well as techniques for 
port scanning, operating system fingerprinting and visualized 
network mapping from haceroute date, they cannot cjalm them 
as Trade Secrets- 
Read my nesponses along side of his Declaration, 

1) True enough 

2) Notice how he makes it specific who their target 
audience/market This Is not the same as mds which is 
releasing small command line tools for the general network and 
security admin. 

3) No problem with this * 



Related links 



I 



Ifloje about, Uga I Issues 
jhJews by sgajgg 



Most read story In Legal 
Issues; 
MyRfghtto.w.oxK 
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4) I question the actual costs/hours. From my calculations a 
single persons's full time hours for a year come out to about 
2,000. To account for 00,000 would mean 20 people Of took 
average annual salary/cost) working on ft full time for the last 

- two years Its been In development 
.Ooesrtt seem accurate-, butlts not an Important point to the 
case-, but one that he repeats several times, so I felt I should 
shoot.lt down up front 

5) For sure their source code, and databases are their own. 
Possibly the actual algorithm fat calculating their often 
discussed TbundScore", Other than thatl am not personally 
aware of any other Trade Secrets that they have. 

6) He says In this that FOundScan Is the heart of Foundstone's 
business. This )% doe* not make sense In terms or revenue as 
tar as I know. Fbundstone has been a very successful 
"Consulting and Training" company up until their recent release 
of fourriScan.Idontseehowanewpr^ . 
a limited number of copies has outstripped their long 
estabfehed consulting and training business. 

7) What he Is talking about Is operating system "fingerprinting" 
for "OS identfV This Is a very common and well understood 
process In the Industry. Yes they have their proprietary 
implemented™, but "fingerprinting' 1 and "GS IdenT (which we 
dont even do yet) Is certainly not soma Trade Secret to 
Foundstone. . ' 

8) Again, they have their own proprietary Implementation, but 
visually mapping a network based on traceroute data Is well 
understood and exists in many products. In Stu's own book he 
talks aboutCheqps which does this and has existed far longer 
than FoundScan. 

9) Again, they have thetr own proprietary Implementation and 
technique for automated vulnerability testing, put as far as £ 

. ■ know ail of the vulnerability checks they {and just about anyone 

. else) do are well described on sites such as SfiCtirfty.pocus, 
THey then display this In a spherical map which they have 
examples of on their own websites how be stni thinks this Is a 
trade secret Is a mystery to me. Regardless, this is not 
something we are even doing. 

10) Again, they have their own proprietary Implementation, but 
this Is Just talking about a web Interface to an application* If I 
had stolen their code, this Is a problem. Finally, I am not even 
doing anything oven remotely simllair for NTO. 

XX) Again, they have their own proprietary Implementation, but 
Web crawling to Inventory and hack Is a well understood and 
documented process In the security Industry. 
12) Again, they have their own proprietary Implementation, but 
most of this te just trend reporting, stuff that tools like 
Microsoft Excel and Crystal Reports have been doing for years. 
Trending Is trending Is trending. The mentioned "scoring 
. • system" *ls potentially* a secret algorithm, but one that they 

talk about the details of m the Hacking Exposed book and other 
forums. But I do think the exact algorithm ttsdf Is a secret,, 
one which I dont even know. This Is also not something 'we are ■ 
doing at mo. 

13 - 17) I have no problem with these 
18) This Is not entirely true. I wont go Into the details.,, but up 
till very recently some parts were plain text. Regardless, the 
general point Is true enough. 
19 & 20) No problem with these 
21) TOs Is not true. The documents I have seen from the 
purchase do not cover NTO Scanner, so the word "ail" Is not 
• accurate.Whats more is that scanning is the heart of the Fire & 
Water toolkit So we already had code to work from, I done 
know if any of the old scanner code was actually used for the 
new scanner/ but we had some to use none the less, 
22 & 23) No problem with these 

24) This is kind of lame and as for as im aware they knew fU < L 

pVMIBI T flT P AGE^j — OF1 
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• • about his teste to brlngNTOback to life. Additionally NTO Is 

*not* a direct competitor to Fbundstone. We happen to be 
another computer, security tool company»» but that does not 
make us a direct competitor since we are not tangattlng their 
Fortune 500 market with ^ like product. 
25 - 30) No problem with these 

31) He calls the 3 functions, "proprietary functions" which 
means that the given functionality and not just their 
Implementation Is proprietary. I am pretty surethe only way to 
make a *runctton w proprietary is to get a Patent, which they do 
not have and could not get because of the vast amount of prior 
art. Point 1 Is Just a network map from traceroute data, as 
mentioned before. Also he calls oiiuro neaify Identical to Jfaejt 
map. See for yourself his exageratton. Number 2 seems to 
Indicate that using a hypertext solution for reporting (aka 
HTML) Is not allowed. For one, we dont even have such a 
tooL r tor another we almost exduslvety use XML and XSLT for 
all of ow data and reporting, AND Its not a trade secret to Use 
HTML for a report! Number 3 Is again not something we even 

- have a product to do, and Its no trade secret. 

32) X take great personal Issue with this. The HIS teams 
happens to be some of the best from their own development 
team, I have proven to him and the entire development team 
on a couple occasions what I can accomplish In a short period 

' of time. I wrote thelr'entlre web Interface to scan management 
In about 3 weeks when I .first started with the company. I also 
wrote ttielr vulntrak app In about a month. The other 
developers at NIQ-are even probably even better programmers 
than X am. This Is really just a personal Insult*, and its also not 
true. We have produced rapidly... but even then we had Just 
barely been ready to release the products, What we showed at 
Blackhat was demo 1 * and mocjcn^s for the most part 

33) No problem with this 

34) This Is.so lame. First the security Industry has been built on 
disclosure of techniques for hacking and securing. The point 
that their fortune 500 customers would forgo buying a $150k 
software package that Integrates over a bunded features and 
provides enterprise scalability and management, for a set of 
DOS PROMFT/Oommand Line utilities Is a Joke! 

35) Yes, so we are not rich I do have a problem with that- 
but thats not an Issue for this ;-) 

36) I have made rny_case against thfs lame point, but I will wait 
for him to' explain Eoundstanels. Free tools and Stuarts own 
book called Backing Exposed which explains In great detail the 
methods of hacking. 

37 - 39) No problem with these. 

In the end I hope I have explained how weak their case Is, T 
wllf state again that °WE HAVE NOT STOLEN THEIR CODE OR 
" AN YjyiING THAT IS THEIR ACTUAL TRADE SECRETS 11 . We 
have our own Ideas, our own code and our own products, X 
wish Fbundstone would just leave us atone, stop bluffing and 
trying to make us bum our money on the legal costs for 
defending ourselves. I encourage anyone that wants to, to 
email them and give them your opinions (pro or con, thaj: la 
your choice). 

I do hope you encourage them to back off and let us go about 
. our business and them go back to theirs. 

Dan KuykendaP 

Legal Docs; The response to their complaint | Login/Create an account 1 0 Comments 

Thiphoidi^iatTiveKj. ; ; a b^m. „\.A 

Comments are owned by the poster. We arerit responsible for their content 
Home ■ Topics - Downloads ■ Your Account • Submit News - TopUst 

EXHIBIT fj ..JAgE^QF^ 
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Darrell L. Olson, Bar No. 77,633 
Michael K. Friedland, Bar No. 157,217 
Douglas T. Hudson, Bar No. 210,385 
KNOBBE, MARTENS, OLgON & BEAR, LLP 
2040 Main Street 
Fourteenth Floor 
Irvine, California 92614 

(949) 760-0404 (telephone) 

(949) 760-9502 {facsimile) 

Attorneys for Plaintiff FOUNDSTONE, INC* 



SUPERIOR COURT OF THE STATE OF CALIFORNIA 
COUNTY OF ORANGE, CENTRAL JUSTICE CENTER 




OCT 0 4 20G2 

BY J, is / 



FOUNDSTONE, INC. , a Delaware 
corporation, 

Plaintiff, 



NT Objectives, Inc., a 
California -corporation; J.D. 
Glaser, an individual; Michael 
Morton, an individual; Eric 
Caso, an individual; Dan 
Kuykendall, an individual; and 
DOES 1 through 50, inclusive, 



Defendants . 



CASE NO. 02CC153 0 

ASSIGNED FOR ALL PURPOSES TO: 
COMMISSIONER ELEAHOR M. PALK 
DEPT. C62 

DECLARATION OF STUART MCCLURE 
IN SUPPORT OF PLAINTIFF'S 
APPLICATION FOR TEMPORARY 
RESTRAINING ORDER AND 
PRELIMINARY INJUNCTION, 
REQUEST FOR EXPEDITED 
DISCOVERY, AND REQUEST FOR 
FILING UNDER SEAL 

HEARING DATE: Oct, 4, 2002 

TIME: * 1:30 p.m. 

DEPT: C62 

TRIAL DATE: None- 

COMPLAINT FILED: Oct. 2, 2002' 



I, Stuart McClure, declare: 

1. I am the President and Chief Technology Officer of 
Foundstone, Inc., Plaintiff in the above-titled action, j 
have served as President and Chief Technology Officer of 
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Foundstone since 1999, The following is true of my own 
personal knowledge; and if called and sworn as a witness, I 
could and would testify competently thereto. 

2. Foundstone specialises in computer network security 
and provides network security audits, education services, and 
security software for Fortune .500 companies , government 
agencies, and others worldwide. 

3* Foundstone 's principal product is FoundScan, a 
unique proprietary software system that automatically scans 
computer networks, tests networks for "hacking" 
vulnerabilities, provides detailed graphical reports and maps 
of tested networks and vulnerabilities, scores the security of 
networks, and reports on results of those tests. 

4. Over the past three years, Foundstone has invested 
more than $4 million dollars and more than 90,000 person-hours 
in research, development, and testing of the proprietary 
FoundScan software. 

5. Foundstone ' a proprietary FoundScan software contains 
a number of well -guarded algorithms, methods and databases 
that are highly valuable trade secrets of Foundstone', In 
particular, FoundScan contains trade secret software 
technology relating to securing corporate and government 
computer networks against hackers, cyber- terrorists*, and 
electronic espionage. 

6. This trade secret technology is the heart of 
Foundstone 's business, and its value would be substantially 
diminished if it were to fall into the public domain. So long 
as the technology continues to be maintained as secret, 
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competitors . and potential competitors would have to invest 
similarly large amounts of time and money to develop systems 
with similar capabilities to compete. 

1. Foundstone's proprietary methods and databases for 
operating system identification include techniques for sending 
TCP (Transmission Control Protocol) and ICMP (Internet Control 
Messaging Protocol) packets to a target computer, which then 
responds with .packets of its own. Based on the target 
computer's response, the operating system of the target 
computer is identified against a proprietary database. 

8. Foundstone's proprietary methods and databases for 
determining and graphically mapping a computer network include 
methods for ICMP and TCP tracerouting to all devices, 
analyzing the results of- the tracerouting to understand the 
placement of those devices on the network, and then visually 
displaying those devices in a three-dimensional map, 

9. 'Foundstone's proprietary methods and databases for 
detecting network vulnerabilities and reporting them with the 
network map include methods for sending a series of packets to 
a target device to pirompt a particular response. Once the 
response is collected, it is analyzed and compared to a series 
of rules that define a vulnerable device. Once identified as 
vulnerable, the device is then associated with a device 
discovered during the network mapping stage, and the result is 
displayed on the three-dimensional spherical map, 

10. Foundstone's proprietary methods and databases for a 
remote administration web interface include methods for- 
alerting a user of newly discovered vulnerabilities, 
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proprietary databases of vulnerabilities, tracking of 
discovered vulnerabilities through a workflow process of 
fixing them, displaying reports of found vulnerabilities, 
displaying threat information, displaying and controlling the 
status of scans, managing user and administrative roles within 
the web interface, and searching the proprietary database for 
relevant vulnerability information. 

11. Foundstone's proprietary web modules for 
vulnerability testing of web servers include methods for 
"crawling" a web site for links, inventorying the technologies 
in place, "brute forcing" authentication mechanisms to unearth 
easy-to-guess passwords, guessing the names of existing but 
not readily linked- to files, testing for poor script input 
validation, and testing for source code disclosure issues. 

12. Foundstone's proprietary methods and databases for 
reporting vulnerability results over time include methods for 
an objective security scoring mechanism, a breakdown of 
network inventory by live hosts, services open, a 
vulnerability network map, operating systems running, 
vulnerabilities found, web module analysis, and trending of 
these results over time* 

13. Poundstone has taken extensive steps to protect the 
trade secrets contained in the FoundScan software, as is 



24 necessary to protect the substantial economic and competitive 



25 
26 
27 
28 



value of Foundstone's trade secrets. These secrets provide 
efficient network scanning, effective graphical mapping of 
networks and vulnerabilities on those networks, and 
understandable reports on network security. 
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14* Foundstone protects its software internally with 
passwords, "software source safes,'' firewalls and other 
network security measures, 

15. Foundstone's physical facilities are protected by 
security measures including closed-circuit cameras, security 
badges, and biometric devices . 

16. All of Foundstone's customers are under strict non- 
disclosure agreements and covenants not to reverse engineer 
FoundScan. Attached as Exhibit W A" to this declaration are 
true and correct copies of three example non-disclosure 
agreements of the type signed by Foundstone's customers. 

17 . FoundScan service customers do not have any access 
to the FoundScan software. These customers only interact with 
the software through a web interface, while the software runs 
from computers controlled by Foundstone. 

18. The few FoundScan customers who do have access to 
the FoundScan software only have access to object code, 

15, All of Foundstone's employees, including Defendants 
iT.D. Glaaer ( w Glaaer ff ) , .Michael Morton ("Morton"), Eric Caso 
(*Caso") and Dan Kuykendall ("Kuykendall" ) , signed agreements 
recognizing the trade secret status of its software and 
research. Attached as Exhibit U B" to this declaration are 
true and correct copies -of the agreements signed by each of 
the above-named individuals. 

20, All of Foundstone's employees, including Defendants 
Glaser, Morton, Caso, and Kuykendall, signed non-disclosure 
agreements as part of their agreements promising not to 
divulge Foundstone's trade secrets, and they stipulated and 

- EF- 
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secrecy." Vacco Industries, Inc. v. Van Den Bercr , 5 Cal.App. 
4th 34, 50 [quoting Cal. Civ. Code § 3425.1(d)]. 

Misappropriation of a trade secret includes " [d] isclosure 
or use of a trade secret of another without express or implied 
consent by a person who * . . (B) At the time of disclosure or 
use, knew or had reason to know that his or her knowledge of 
the trade secret was; . . > (ii) Acquired under circumstances 
giving rise to a duty to maintain its secrecy or limit its 
use; or by improper means of disclosure including breach of 
duty to maintain secrecy. " FMC, Inc. v, Kadiaha , (2000) 78 
Cal.App.4th 1368, 1382-83 (quoting Cal . Civ. Code § 
3426.1(b)). Because each of these elements are met here, 
Foundstone is likely to prevail on the merits. 

1* Founds tone Has Established the Existence of Trade 
Secrets 

The Uniform Trade Secrets Act defines a trade secret as 
"information, including a formula, pattern, compilation, 
program, device, method, or technique, or process that [] 
derives independent economic value, actual or potential, from 
not being generally known to the public or to other persons 
who can obtain economic value from its disclosure or use." 
Cal. Civ, Code § 3426.1(d) . Schlage Lock Co. v. Whyte . 2002 
Cal.App. LEXIS 4634, *13 (Cal. App. 4th Dist. Sept. 12, 2002) 
(affirming trade secret status of misappropriated materials) . 

Foundstone's technologies certainly meet this definition. 
The Foundstone technologies at issue are: 

(1) Foundstone's proprietary methods and databases for 
operating system identification, which include techniques for 
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sending TCP (Transmission Control Protocol) and 1CMP (Internet 
Control Messaging Protocol) packets to a target computer, 
which then responds with packets of its own. Based on the 
target computer's response, the operating system of the target 
computer is identified against a proprietary database of over 
eight hundred operating system u f ingerprints ♦ ", (McClure 
Decl., 1f7.) 

(2) Foundstone's proprietary methods and databases for 
determining and graphically mapping a computer network, which 
include ICMP and TCP tracerouting to all. devices, analysing 
the results of the tracerouting to understand the placement of 
those* devices on the network and then visually displaying 
those devices in a three-dimensional map, (Id., 118.) 

(3) Foundstone's proprietary methods and databases for 
detecting network vulnerabilities and reporting them with the 
network map, which include sending a series of packets to a 
target device to prompt a particular response . Once the 
response is collected, it is analyzed and compared to a series 
of rules which Refine a vulnerable device. Once identified as- 
vulnerable, the device is then associated with a device 
discovered during the network mapping stage, and the result is 
displayed on the three-dimensional spherical map- (Id., 1f9.) 

(4) Foundstone's proprietary methods and databases for a 
remote administration web interface, which include alerting a 
user of newly-discovered vulnerabilities, proprietary 
databases of vulnerabilities, tracking of discovered 
vulnerabilities through a workflow process of fixing them, 
displaying reports of found vulnerabilities, displaying threat 
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information, displaying and controlling the status of scans, 
managing .user and administrative, roles within the web 
interface, and searching the proprietary database for relevant 
vulnerability information. (Id. , 1[10.) 

(5) Foundstone' s proprietary web modules for 
vulnerability testing of Web servers, which include "crawling" 
a web site for links , inventorying the technologies in place, 
"brute forcing" authentication mechanisms to unearth easy-to- 
guess passwords, guessing the names of existing but not 
readily linked-to files, testing for poor script input 
validation, and testing for source code disclosure. {Id., 
HH-) 

(6) Foundstone's proprietary methods and databases for 
.reporting vulnerability results over time including an 
objective security scoring mechanism, a breakdown of network 
inventory by live hosts, services . open, a vulnerability 
network map, operating systems running, vulnerabilities found, 
web module analysis, and trending of these results over time. 
(Id./ 1112.) , _ 

These technologies are not generally known to the public 
or to those who could obtain economic value from their 
disclosure or use. As discussed above, Foundstone created 
these technologies only through investing 80,000 person-hours 
and $4,000,000 of research and development. (Id;, 114.) 

These technologies also derive value from their secrecy . 
The resulting technologies are valuable to Foundstone only 
because - and only for so long as - the technologies are 
secret. (Id., 116.) Foundstone is able to market its software 
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and services effectively because it offers a product that is 
unique. (id., 1f3.) So long as the technologies continue to 
be maintained as secrets, competitors and potential 
competitors would have to invest similar large amounts of time 

and money to develop systems with similar capabilities "to 

f 

compete with Foundstone . (Id., H6 .) If the technologies were 
to be disclosed, entities could compete with Foundstone 
without having to make these* investments, thereby devastating 
the market position Foundstone established as a result of ifca 
huge research and development investment. (Id,) 

2 * Foundstone Has Taken Far-Reaching Steps to Protect 

the Secrecy of its Technologies 
As described above, Foundstone has taken extensive steps 
to protect the confidential status of its trade secrets. 

Foundstone protects its software internally with 
passwords, firewalls, "software source safes, 7 ' and other 
network security measures. (Id. f H1F13-14.) Foundstone' s 
physical facilities are protected by security measures 
including "biometric" security devices, (Id-, 115) 

All of Foundstone' s customers are under strict non- 
disclosure agreements and covenants not to reverse engineer. 
(Id., Tf 16 & Ex. A) Foundstone 's service customers do not have 
any access to the Foundstone' s software. These customers only 
interact with the software through a web interface while the 
software runs on computers controlled by Foundstone. (Id., 
Ul6.) The few Foundstone customers who have access to 
Foundstone's software only see object code, (Id- , TI17) . 

All of Foundstone' &. employees, including the individual 
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Defendants, signed agreements recognising the trade secret 
status of Foundstone' s software and research. (Id., 1119-20 & 
Ex. B „ ) In addition, all of Foundstone's employees, including 
the individual Defendants , signed non-disclosure agreements 
promising not to divulge Foundstone's trade secrets. (Id.) 

3, Defendants Indisputably Had Access to Founds tone '& 
Trade Secrets 

There can be no dispute that Defendants had access to 
Foundstone's trade secrets* Each of the individual Defendants 
was employed by Foundstone and, while at Foundstone, had key 
roles in developing the trade secret technologies that are at 
issue in this Motion. (Id., 1f29 J Defendant NTO was founded 
by and consists of the individual Defendants. (Id.) 

4. Defendants 1 Release of Their Software Would Breach 
Their Duties to Maintain Secrecy 

Each of the individual Defendants executed employment 
agreements that included comprehensive nondisclosure 
provisions. (Id., H19 & Ex, B.) By releasing software 
containing Foundstone's trade secret technologies, Defendants 
would certainly be breaching their obligations of 
confidentiality pursuant to their' agreements with Foundstone, 

Because the evidence establishes both that the balance of 
the hardships weighs dramatically in favor of Foundstone and 
that Foundstone is likely to prevail on the . merits, this Court 
should temporarily restrain and preliminarily enjoin 
Defendants from using or disclosing Foundstone's trade 
secrets. Vacco Industries, Inc. , 5 Cal . App. 4th 34, 53-54; 
Merrill Lynch, 2001 U.S. Dist. LEXIS at *14-*17- 
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grant the preliminary injunction. " ) ; 

C» The Facts Establish Likelihood Of Succeaa 

The second prong of the two-part test for injunctive 
relief is likelihood of success on the merits. Foundstone has 
clearly established that it i3 likely to succeed. 

1- Foundstone' s Specified Methodg and Techniques Are 
Protectable Trade Secrets 

In its moving papers, Foundstone submitted detailed 
evidence that its methods and techniques in six specific areas 
constituted protectable trade secrets. (Memo, at 9-11.) In 
response, Defendants have raised a number of arguments. All 
lack merit. 

(a) The Trade Secrets Are Adequately Defined 
Defendants argue that Foundstone has not identified its 
trade secrets with sufficient particularity. (Opp. at 6-8.) 
To make this argument, Defendants ignore the specific 
identification of trade secrets contained in Foundstone* 8 
moving papers and claim that Foundstone only generically 
stated w that Foundstone' s software contains x algorithms, 
methods, and databases.'" (Id. at 6.) This is simply 
incorr ec t . Foundstone 'a inoving_ papers stated that its trade 
secrets related to six specifically described technologies 9 
The detailed description of these technologies spanned two 
full pages of Foundstone' s brief , {Memo, at 9-11; McClure 
Decl.* HH 5-12, J 1 



1 Defendants' reliance on Diodes, Inc. v. Franzen , .2 60 

Cal,App»2d 244 (1968) is misplaceST m mooes" ; the plaintiff 

simply referred to a ^secret process.'' In contrast, 

-5- 
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Defendants similarly assert that they are unable to 
understand the described trade secrets. ( See , e,q. , Glaser 
Decl. U 26.) Such assertions are implausible,, given that the 
Defendants themselves allege that they had critical roles in 
developing Foundstone's software. ( See , e.g , id» H 38.) The 
assertions are also thoroughly repudiated by Defendants' own 
declaration; The declarations discuss specific methods and 
algorithms allegedly implicated by the claimed trade secrets 
in great detail. (Caso Decl. ^% 12-18; Glaser Decl. 16-19; 
Morton Decl. H 16-19, ) 2 See Whyte v. Schlage Lock Go. , 101 
Cal.App.4th 1443 , 1453 (2002) (rejecting assertion that trade 
secrets were defined too broadly where , from responses to 
discovery, it was clear that former employee had ft no 
difficulty in understanding the scope of the putative trade 
secret information.") 

Moreover, the scope of trade secrets are specifically 
limited to methods developed by pounds tone . (Memo, at 9-11,) 
The Court of Appeal has specifically held that an injunction 
"need not specify in detail the processes whose use is 
prohibited." Components For Research, Inc. v. Isolation 
Prods Inc. , 241 Cal,App*2d 726, 731 (1966) • Instead, it is 



Poundstone has provided pages of detail describing the trade 
secrets at issue* Defendants' reliance on MAI Sys, Corp. v. 
Peak Computer , 991 F.2d 511 (9th Cir» 1993) r is also 
misplaced. In MAI , the plaintiff cryptically referred only to 
^valuable trade secrets" in software, without any further 
explanation whatsoever. 



z Defendants also assert that Foundstone has not complied 
with CC.P. § 2019(d) . This, too, is incorrect. Foundstone 
served a disclosure pursuant to Section 2019(d) on October 15, 
2002. 

-6- 
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sufficient to describe the technology and specifically limit 
the scope of an injunction to "method [s], technique [s] , or 
processes . . . developed by the" plaintiff." Id. (Emphasis 
added.) For the additional reason that the trade secrets 
claimed here are all specifically limited to methods developed 
by Founds tone, the trade secrets are described in more- than- 
sufficient detail. 

(b) The Trade Secrets Are Not Public Domain 
Defendants also argue that Foundstone' s trade secrets are 

"based on information available in the public domain." (Opp. 
at 10.) This assertion is utterly irrelevant * Foundstone 
does not dispute that its trade secrets rely, in part, on 
known principles * Defendants, however, never claim that any 
of the publications or software they refer to in their papeirs 
discloses the actual methods Foundstone developed . 3 They do 
not dispute that the massive investment Foundstone had to make 
to create its software- (McClure % 4.) Indeed, Defendants 
admit that, to duplicate the functionality of Foundstone 's 
software, it would be necessary for a competitor to make a 
similar investment of money and effort- (Glaser 1 31.) 

(c) Reasonable Efforts To Maintain Secrecy 
Defendants also aBsert that Foundstone did not take 

reasonable efforts to protect the secrecy of the software. 



The 152-page Exh, F to the Glaser Decl. is typically 
irrelevant to the trade secrete in this case. Defendants 
suggest that this document somehow discloses Foundstone 's 
proprietary TCP and ICMP methods of operating system 
identification. The document, however, merely discusses 
general ICMP methods of network scanning, not the techniques 
developed by Foundstone.. 

-7- 
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(Opp. at 10*) Defendants do not dispute the comprehensive 
steps Foundstone has taken to protect its trade secrets. 
{McClure Decl. 13-20 -) Instead, Defendants point only to 

Foundstone 's alleged provision of evaluation copies of its 
software to reviewers, which would have theoretically allowed 
a reviewer to *read, write , or print" a single database, 
(Caso Decl. % 15,) Defendants never claim that the data ™ an 
unintelligible mixed series of binary, decimal , and 
hexadecimal numbers - could be used or even understood by 
anyone. Defendants never state that any source code, or any 
means by which anyone could use or understand the allegedly 
compromised database was disclosed. Accordingly, there is no 
serious dispute that Foundstone took reasonable steps to 
protect its trade secrets. 

2 . Defendants Have Misappropriated And Threatened To 
Misappropriate Founds tone' s Trade Secrets 

In its moving papers, Foundstone submitted detailed 
evidence establishing that Defendants had misappropriated and 
threatened to misappropriate its trade secrets, citing to 
specific features of Defendants' software, (McClure Decl. flfl 
30-32.) 4 In their Opposition, Defendants do not dispute 
(indeed, they admit) that their software contains these 
features. (Caso Decl. Exh. C; Glaser Exh. E.) Moreover, 



4 Although Defendants assert objections to paragraphs 30- 
32 of the McClure Decl , , they do not dispute the information 
presented. Moreover, the statements in paragraphs 30-32 of 
the McClure Decl. are confirmed by Defendants' own 
descriptions of their software. (Caso Decl. Exh. C; Glaser 
Decl. Exh. E.) 

; I 8- 
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Plaintiff Foundstone, Inc. ( * Pounds tone" ) submits this 
Supplemental Reply in Support of the Order to Show Cause Ret,: 
Preliminary Injunction. The information, addressed in this 
Supplemental Reply disproves a key assertion made by 
Defendants in their Opposition, The information was not 
discovered by Foundstone until after Foundstone filed its 
Reply on October 25, 2002. 

In their Opposition, Defendants repeatedly argue that it 
is "impossible" for the Defendants to determine the trade 
secrets that are the subject of this action, (Opp. at 2. See 
also id. at 6-9,) The Defendants themselves submitted 
declarations, each asserting, in lock-suep: "I have read the 
Declaration of Stuart McClure submitted in support of this OSC 
re: Preliminary Injunction* From review of that document I am 
unable to determine any specific method, algorithm or 
technique which is being referred to by Foundstone as a trade 
secret." (Caso Decl. 1 13; Glaser Decl. 26; Kuykendall 
Decl. U 15; Morton Decl. f 16,) 

Information just uncovered by Foundstone demonstrates 
that these assertions are false. As set forth in Exh. A to 
the Hudson Decl. submitted herewith, Defendant Kuykendall 
maintains a personal site on the World Wide Web, On his web 
site, Defendant Kuykendall published a paragraph -by- paragraph 
critique of the McClure Decl,, specifically addressed each of 
the paragraphs of the McClure Decl. describing the trade 
secrets at issue in this action, and unambiguously admitted 
that he understood that Foundstone has proprietary fcechnolocry 
in each described area . The McClure Decl. described the trade 
-2- 
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secrets at issue in paragraphs 7-12. In his web site, 
Defendant Kuykendall responded to each of these paragraphs ' by 
admi 1 1 ing , inter alia , "they tFoundfltone] have their 
proprietary implementation . " (Hudson. DecL Ex. A p. 3, \\ 7- 
12 ? emphasis added . ) 

For this additional reason, Founds tone requests that this 
Court preliminarily enjoin Defendants and maintain the status 
quo pending final adjudication of this matter. 

Respectfully Submitted* 

KNOBBE, MARTENS, OLSON & BEAR, LLP 



Dated 



By; 




Darre_ ^ 
Mi chael k.. Fri edl and 
Douglas T. Hudson 
Attorneys for Plaintiff 
FOUNDS TONE , INC* 
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Introduction 

1.1 Introduction to Version 1.0 . 

The ICMP Protocol may seem harmless at first glance. Its goals and features were outlined In 
RFC 792 (and than later cleared in RFCa 1122, 1256, 1349, 1012), as a way to provide a means 
to send error messages. In terms of security, ICMP Is one of the most controversial protocols in 
the TCP/IP protocol suite. The risks involved In implementing the ICMP protocols a network, 
regarding scanning, are the subject of this research paper. 

Scanning will usually be the major stage of an information gathering process a malicious 
computer attacker will lunch against a targeted network. With this stage the malicious computer 
attacker will try to determine what are the characteristics of the targeted network. He will use 
several techniques, such as host detection, service detection, network topology mapping, and 
operating system fingerprinting. The data collected will be used to Identify those Hosts (if any) 
that are running a network service* which may have a known vulnerability. This vulnerability may 
allow the malicious computer attacker to execute a remote exploit in order to gain unauthorized 
access to those systems. This unauthorized access may become his focal point to the whole 
targeted network. 

This research paper outlines the usage of the ICMP protocol In the scanning process. Step-by- 
Step we will uncover each of the malicious computer attacker techniques using the ICMP 
protocol. A few new scanning techniques will be unveiled In this research paper. I have reported 
some of them to several security mailing lists* including Bugtraq, in the past. 

The chapters in this research paper are divided according to the various scanning techniques: 

• Host Detection using the ICMP protocol Is dealt in Chapter 2. 

* Advanced Host Detection methods. using the ICMP protocol are discussed In Chapter 3. 

• Inverse Mapping using the ICMP protocol is discussed In Chapter 4. 

* Network Mapping using the traceroute utility is discussed in Chapter 5. 

* Chapter 6 discusses the usage of ICMP In the Active Operating System Fingerprinting 
process. 

• Chapter 7 suggests a filtering policy to be used on filtering devices when dealing with the 
ICMP protocol. 



I would like to take a stand in this controversial issue, 
known. I hope this research paper will change this fact. 



ICMP protocol hazards are not widely 



1.2 Introduction to Version 2.0 

Quite a large number of new OS fingerprinting methods using the ICMP protocol, which I have 
found are introduced with this revision. Among those methods two can be used In order to Identify 
Microsoft Windows 2000 machines; one would allow us to distinguish between Microsoft 
Windows operating system machines and the rest of the world, and another would allow us to 
distinguish between SUN Solaris machines and the rest of the world 1 . I have also tried to be 
accurate as possible with data presented In this paper. Few tables have been added to the paper 
mapping the behavior of the various operating systems I have used. These tables describe the 
results I got from the various machines after querying them with the various tests introduced with 
this paper. 

See section 1 .3 for a full Changes list. 



See Section 6 for more information. 
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1 .3 Introduction to Version 2.5 

With this version of the research paper I am introducing a few new OS fingerprinting methods. 
Some are targeted in producing ICMP error messages from a target OS, enabling us to fingerprint 
an OS even if all ports of the OS in question are closed. I have also added a considerable amount 
of information about ICMP error message. At the end of the paper you will find the Basic snort 
rule base 1 have written. 



1.4 CHANGES 

1.4.1 Version 1.0 to Version 2.0 

2,0 Host Detection Using the ICMP Protocol. 

2.3 Broadcast ICMP 

Added a table describing which operating systems would answer an ICMP ECHO 
request aimed at the Broadcast address of the network they reside on. 

2.4 Non-ECHO ICMP 

Added Information Request and Reply as a valid Host Detection method. 

2.4.2 ICMP Information Request and Reply 

The actual Information (added a section). 

2.4.3 ICMP Address Mask Request and Reply 

Added SUN Solaris and networking devices examples. 

2.5 Non-Echo ICMP Sweep 

Added a table summarizing which operating systems would answer those 
queries. 

2.6 Non-ECHO ICMP Broadcasts 

Added the feet that "Hosts running an operating system, which answers 
requests aimed at the IP broadcast address.. / 

Added two tables describing which operating systems would answer to which 
type of ICMP queries aimed at the broadcast address of the network they reside 
on? 

3.0 Host Detection Using ICMP Error messages generated from the probed machines 

3.1 IP datagrams with bad IP Header fields 

Added more Information on various other, fields which can be used for this 
purpose. 

6.0 The Usage of ICMP in the operating system Finger Printing Process 

G.1 Using Wrong Codes within ICMP Datagrams 

6.1.1 Using ICMP Timestamp Requests with Codes different than 0 

6.1.2 UstJng ICMP query message types sent to different operating systems 

with the Code field !=0 and the answers (Is any) we got. 

6.2 Using ICMP Address Mask Requests (Identifying Solaris Machines) 

6.3 TOSlng OSs out of the Window / Fingerprinting Microsoft Windows 2000 

6.7 Using ICMP Address Mask Requests 

6.8 Using ICMP Information Requests 

6.9 identifying operating systems according to their replies for non-ECHO ICMP 

requests aimed at the broadcast address. 

6.10 IP TTL Field Value with ICMP 

6.10.1 IP TTL Field Value with ICMP ECHO Replies 

6.10.2 IP TTL Field Value with ICMP ECHO Requests 
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6.11 DF Bit 

6.12 DF Bit Echoing 

6.12.1 DF Bit Echoing with IGMP Echo requests 

6.12.2 DF Bit Echoing with ICMP Address Mask requests 

6.12.3 DF Bit Echoing with ICMP Timestamp requests 

6.12.4 Using all of the Information In order to Identify the maximum of operating 

systems. 

6.12.5 Why this would work (for the skeptical) 

6.13 What will not provide any gain compared to the effort and the detection ability? 

6.13.1 Unusual big ICMP Echo messages 

7.0 Filtering ICMP on your Filtering Device to Prevent Scanning Using ICMP 

7.3 Other Considerations 

More information was added. 

Appendixes 

Appendix C: Table - Mapping Operating Systems for answering/discarding ICMP query 
Message types. 

Appendix D: Table - ICMP Query Message Types with Code Field l=0 
Appendix E: Table - ICMP Query Message Types aimed at a Broadcast Address 
Appendix R Table - ICMP Query Message Types with TOS 1=0 
Appendix G: Table - DF Bit Echoing 



1.4.2 Version 2.0 to Version 2.01 

The Introduction was re-written 



1.4.3 Version 2.01 to Versron 2.5 

To Section 4 "Inverse Mapping" more information and explanations were added. 
Section 6 is now divided into four main subjects; 

• Fingerprinting using regular ICMP Query requests 

• Fingerprinting using crafted ICMP Query request 

• Fingerprinting using fCMP Error Messages 

• Not that useful fingerprinting methods 



Multiple new fingerprinting methods based on ICMP Error Messages were introduced. 

I have also Introduced few Fingerprinting method based on ICMP Query messages: "Using the 
Unused (Identifying Sun Solans & HP-UX 10.30 & 11, Ox)", "Precedence Bits Echoing (WIn2k> 
ULTRIX Identification)", The TOS Byte Unused Bit Echoing (Identifying Wln2k, ULTIX)". 

The DF Bit Playground" fingerprinting method was better explained and explored. 

Appendix A now includes explanation for the various ICMP Error Messages. 
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2.0 Host Detection using the ICMP Protocol 2 

The Host Detection stage gives a malicious computer attacker crucial information by Identifying 
the computers on the targeted network that are reachable from the Internet. This process belongs 
to the scanning stage, which is one of the first stages In the Information Gathering process. The 
information collected during this stage could later lead to an attempt to break in to one (or more) 
of the targeted network computers. Thls t if the information gathered would be sufficient for the 
malicious computer attacker. 



2.1 ICMP ECHO (Type 8) and ECHO Reply (Type 0) 

We can use an ICMP ECHO datagram to determine whether a target IP address Is active or not, 
by simply sending an ICMP ECHO* (ICMP type 8) datagram to the targeted system and waiting 
to see If an ICMP ECHO Reply (ICMP type 0) is received, tf an ICMP ECHO reply is received, it 
would indicate that the target is alive (few firewalls spoof ICMP ECHO replies from protected 
hosts); No response mean3 the target is down or a filtering device is preventing the Incoming 
ICMP ECHO datagram from getting inside the protected network or the filtering device prevents 
the initiated reply from reaching the Internet, 



ICMP ECHO request 



+ 

If alive and not filtered - ICMP ECHO 
Reply 

•Figure 1: ICMP ECHO Mechanism 



This mechanism Is used by the Ping command to determine if a destination host fs reachable. 

In the next example two LINUX machines demonstrate the usage of Plng: 

[rootOstan /root]# ping 192. 158,5-5 
"PING 192.168.5.5 (192.168.5.5) from 192.168.5.1 ; 56(64) bytea of data. 
64 bytes from 192% 168. 5.5: icmp_seq=0 ttl*255 time=4.4 rao 
€4 bytes from 192.168.5,5; icmp_seq»l ttl«255 time=5»9 ms 
64 bytes from 192. 168. 5. 5: icrap_seq~2 ttl-2$5 time-5.8 me 

192.168.5.5 pins statistics 

3 packets transmitted, 3 packets received, 0* pacfeet loss 
round-trip min/avg/max « 4.4/5*3/5,9 ma 



A Snort trace 4 : 

01/26-13:16x25. 74G316 192.168.5.1 -> 192.168*5,5 




3 For more Information about the ICMP Protocol plea&o read "Appendix * The ICMP Protocol*. 

3 From a technical point or vfow: The sending sWe Initializes the identifier (used to Identify ECHO requests aimed at 
different donation hosts) and sequence number (ir multiple ECHO requests am sent to the same destination host), adds 
some data (arbitrary) to the data field and sends the ICMP ECHO to the destination host In the ICMP header the code 
equals zero. The recipient should only change the type to ECHO Reply and return the datagram to the sender. 

4 Snort, written by Martin Roesch. can be round at httD:/Aww,snorJ f org. 
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ICMP TTL;64 TOS ! OxO ID;60S9 
ID: 5721 Seq:l ECHO . 

89 D7 BE 38 27 63 OB .00 08 09 OA OB OC OD OE OF . ..B'C * ♦ 

10 11 12 13 14 15 16 17 18 191A IB 1C ID IE IF 

20 21 22 23 24 25 26 27 29 2A 2B 2C 2D 2E 2F 1 *#$%&' ()*+,--/ 
30 31 32 33 34' 35 36 37 01234557 

01/26-13516*25. 746638 192.168.5.5 -> 192.168-5.1 
ICMP TTL:2S5 TOS: 0x0 IDi6072 
ID: 5721 Seqrl ECHO REPLY 

89 D7 8E 3 3 27.63 OB DO OB 09 OA OB OC DD OH OF ...8 f c 

10 11 12 13 14 15 16 17 18 19 1A IB 1C ID IE IF 

20 21,22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F I "#$%&' 0 *+f - - / 
30 31 32 33 34*35 36 37 ' 01234567 



0 4 8 16 31 









Worffler 







Figure 2: ICMP ECHO Request & Reply massage format 



Countermeasure: Block ICMP ECHO requests coming from the Internet towards your network at 
your border router andVor Firewall 5 . 

2.2 ICMP Sweep (Ping Sweep) 

Querying multiple hoste using ICMP ECHO ie referred to as ICMP Sweep (or Ping Sweep). 

For a small to midsize network the Ping utility Is an acceptable solution to this kind of host 
detection, but with large networks (such as Class A, or a full Class B) this kind of scan is fairly 
stow mainly because Ping wafts for a reply (or a thne out to be reached) from the probed host 
before proceeding to the next one. 

fping* is a UNIX utility which sends parallel mass ECHO requests In a round robin fashion 
enabling it to be significantly faster than the usual Ping utility. It can also be fed with IP addresses 
with Its accompanied tool gping. gping is used to generate a list of IP addresses which would be 
later fed Into fping, directly or from a file, to perform the ICMP sweep, fplng Is also able to resolve 
hostnames of the probed machines if using the -d option. 

Another UNIX tool that is able of doing an ICMP sweep in parallel, resolve the hostnames of the 
probed machines, save it to a file and a lot more Is NMAP\ written by Fyodor. 



5 It Is better to filter unwanted traffic at your border router, reducing traffic rates for your firewall. 
* ftp^/ftp.tamu.edu/oub/Unlx/3rc 
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For the Microsoft Windows operating system a notable ICMP sweep tool Is Prnger from Rhino9 8 , 
able of doing what fping and NMAP do regarding this kind of scan. 

Trying to resolve the names of the probed machines may discover the malicious computer 
attacker's IP number used for the probing, using the log of the authoritative DNS server. 

The next example demonstrates the usage of NMAP to perform an ICMP sweep 8 against 20 IP 
addresses. Our test lab contains two LINUX machines running Redhat Unux v6.1, KBmel 2.2.12 
(Stan & Kenny) and one Windows NT WRKS SP4 (Cartman). As it can be seen ell of the 
machines answered the probe: 



[xootGstan /root]# nmap SP -PI 192.168 . 5 .1-20 

Starting nmap V. 2.3BETAJL3 ny fyodor@insecure.org ( 
www, ins ecure.org/nmap/ ) 

Host atan.sys-Becurity.com (192.168.5.1) appears to be up* 

Host Jcenny.sys -security, com (192.168.5.5) appears to be up. 

Host cartman.Bya-security.com (192.168.5.15) appears to be up. 

Nmap run completed -- 20 IP addresses (3 ho^ts up) Bcanned in 3 seconds 



If we wish to avoid the automatic resolving done by NMAP we should use the -n option to 
eliminate it 

ICMP sweeps are easily detected by IDS (Intrusion Detection Systems) whether launched in the 
regular way, or if used in a parallel way. 



Countermeasure: Block ICMP ECHO requests coming from the Internet towards your network at 
your border router and/or Firewall. 



2.3 Broadcast ICMP 

A simpler way to map a targeted network for alive hosts is by sending an ICMP ECHO request to 
the broadcast address or to the network address of the targeted network. 

The request would be broadcasted to all hosts on the targeted network. The alive hosts will send 
an ICMP ECHO Reply to the prober's source IP address (additional conditions apply here). 

The malicious computer attacker has to send only one IP packet to produce this behavior. 

This technique of host detection Is applicable only to some of the UNIX and UNIX-like hosts of the 
targeted network. Microsoft Windows based machines will not generate an answer (ICMP ECHO 
Reply) to an ICMP ECHO request aimed at the broadcast address or at the network address. 
They are configured not to answer those queries out-of-the box (This applies to all Microsoft 
Windows operating systems accept for Microsoft Windows NT 4.0 with service pack below SP4). 
This is not an abnormal behavior as RFC 1122 10 states that if we send an ICMP ECHO request to 
an IP Broadcast or IP Multicast addresses it may be silently discarded by a host. 



1 The RhlnoS group no longer exists. Their tools are available from a number of sites on the Internet ■ 
The -sP -PI options enable NMAP to perform only an ICMP Sweep. The default behavior when using the -sP option is 
different and includes the usage of TCP ACK host detection technique as wel- 
D RFC 1 1 22: Requirements for Internet Hosts - Communication Layers, http^ftvww.ratf.ofq^rfc/rfcl 122^- 
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ICMP Echo Roquest(s) 



Broadcast Address 
Netowrk Address 




Figure 3: Broadcast ICMP 

The next example demonstrates the behayfor expected from hosts when sending an ICMP ECHO 
request to the broadcast address of a network. The two LINUX machines on our test lab 
answered the query while the Microsoft Windows NT 4.0 Workstation with SP6a machine silently 
Ignored it 

Trootestan /root]# ping -b 192.168.5.255 
WARNING: pinging broadcast address 

PING 192.169. 5. 255 (192.168.5.255) from 192.168.5.1 ; 56 (*4) bytes of 
data . 

64 bytes from 192.168.5-1: icmp_Geq^0 ttl»255 time»4.1 ma 

64 bytes from 192.168.5.5* icrnp_aeq-0 ttl-255 time=5.7 ms (DOT!) 

192.158.5.255 ping statistics 

1 packets transmitted, l packeta, received, +1 duplicates, 0* packet 
loss 

round- trip rain/ avg /max =± 4*1/4.9/5-7 tub 

In «ie next example I Have sent an ICMP ECHO request to the network address of the targeted 
network. The same behavior was produced. The LINUX machines answered the ICMP ECHO 
request while the Microsoft Windows NT 4.0 with sp6a machine Ignored it 



[root@atan /rOOt]# ping -b 192*169.5.0 
WARNING i pinging broadcast address 

PING 192.168.5.0 (192.168.5.0) from 192*160.5*1 * 56(54) bytes of data. 

64 bytes from 192.168,5,1: icmp_eeg^0 ttl=»255 time=*7.5 mB 

64 bytes from 192*168,5.5: icmp^Seq-O ttl-255 time-9.1 ms (DUPl) 

192*168,5.0 ping statistics 

1 packets transmitted, 1 packets received, +1 duplicates, 0% packet 
loss 

rounds trip min/avg/max = 7,5/8.3/9.1 ms 

Note; Broadcast ICMP may result in a Denial-Ottervice condition if a lot of machines response 
to the query at once. 
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A more accurate table that lists which operating systems would answer to an ICMP ECHO 
request aimed at their Network / Broadcast address is given below: 



: : ^ . ' ■ > .•• • . 


ECHO KCKJUQ51 

OFLrinjCZKki 


DeWan GNU/ UNUX 2.2, Komei 2,4 test 2 
Redhat LINUX 6.2 Kamal 2^.14 


+ 


FreeBSD 4.0 
FreeBSD 3.4 
OponBSD 2.7 
OpenDSD 2.6 
NetBSD 




Solaris 2.5.1 
Solaris 2.6 
Solaris 3L7 
Solaria ZA 


+ 


HP-UX vlO.20 




AIX 




uumix 




Windows 95 
Window^ 98 
Windows 99 se 

Windows ME 

Windows NT 4 WRKS SP 3 
Widows NT 4 WRKS SP 6a 
Windows MT A Soiver SP4 
Windows 2000 Professional (and SP1) 
Windows 2000 S<*rv&r (and SP1) 





Tablo 1: Which Operating Systems would answer to an ICMP ECHO Request aimed at the Broadcast 

Address of the Network they reside on? 



Countermeasure: Block the IP directed broadcast on the border router. 




2.4 Non-ECHO ICMP 

ICMP ECHO Is not the only ICMP query message type.avallable with the ICMP protocol; 

Non-ECHO ICMP messages are being used for more advanced ICMP scanning techniques (not 
only probing hosts, but network devices, such as a router, as well). 

The group of ICMP query message types Includes the following: 

ECHO Request (Type 8), and Reply (Type 0) 

Time Stamp Request (Type 13), and Reply (Type 14} 

information Request (Type 15), and Reply (Type 16) 

Address Mask Request (Type 1 7), and Reply (Type 1 8) 

Router Solicitation (Type 10), and Router Advertisement (Type 9) 



14 
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2.4.1 ICMP Tims Stamp Request (Type 13) and Reply (Type 14) 

The ICMP Time Stamp Request end Reply allows a node to query another for the current time. 
This allows a sender to determine the amount of latency that a particular network Is experiencing. 
The sender Initializes tha Identifier (used to identify Timestamp requests aimed at different 
destination hosts) and sequence number (if multiple Timestamp requests are sent to the same 
destination host), sets the originate time stamp and sends it to the recipient. 

The receiving host fills in the receive and transmit time stamps, change the type of the message, 
fo time stamp reply and returns it to the recipient The time stamp is the number of milliseconds 
elapsed since midnight UT (GMT). 

The originate time stamp Is the time the sender last touched the message before sending it, the 
receive time stamp is the time the recipient first touched it on receipt, and the Transmit time 
stamp Is the time the receiver last touched the message on sending it. 



16 



31 



iyp<i 



Cote 



Chaieun 



kfcrtftr 



SflqdarcfiNufflfacr 



Ontario frnfieterop 



Figure 4: ICMP Time Stamp Request & Reply message format 



As RFC 1122 state, a host may Implement Timestamp and Timestamp Reply. If they are 
Implemented a host must follow this rules: 

o Minimum variability delay in handling the Timestamp request, 
o The receiving host must answer to every Timestamp request that he receives, 
o An ICMP Timestamp Request to an IP Broadcast or IP Multicast address may be silently 
discarded. 

o The IP source address in an ICMP Timestamp reply must be the same as the specific- 
destination address of the corresponding Timestamp request message. 

o If a source-route option is received in a Timestamp request, the return route must be 
reserved and used as a Source Route option for the Timestamp Reply option, 

o If a Record Route and/or Timestamp option is received In a Timestamp request this 
option(s) should be updated to include the current host and included In the IP header of 
the Timestamp Reply message. 



Receiving an ICMP Timestamp Reply would reveal an alive host (or a networking device) that has 
implemented the ICMP Timestamp messages. 
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In the next example I have sent an ICMP Time Stamp Request, using the Icmpush 11 tool, to a 
Redhat 6.1 LINUX, Kernel 2,2.12 machine; 

r*oot©stan /root]# icmpush -tatamp 192.168.5.5 
kenny.oya-security.com -> 13:48:07 

Snort Trace: 

01/26-13:51:29. 342547 192.1&B.5.1 -> 192.168.5.5 
ICMP TTL*254 TOS:0x0 IDr 13170 
TIMES TAMP REQUEST 

88 16 D8 D9 02 0B 63 3D 00 00 00 00 00 00 00 00 c= 

01/26-13 !51t29. 342805 192,168. 5*5 -> 192.169.5.1 
ICMP TTL:255 TOStOxO ID: 6096 
TIMESTAMP. REPLY 

SS 16 D8 D9 02 es 63 3D 02 00 50 18 02 88 50 IB c-,.P,. >P. 

2A DE 1C 00 AO F9 *... 



When I have sent an ICMP Time Stamp Request to a Windows NT WRKS 4.0 SP4 machine, I got 
no reply. Again, this is not an abnormal behavior from the Microsoft Windows NT machine, Just an 
< Implementation choice as RFC 1 1 22 states. 



Countermeasure: Block ICMP Time Stamp Requests coming from the Internet on the bonier 
Router and/or Firewall. 



2.4*2 ICMP Information Request (Type 15) and Reply (Typo 16) 

The ICMP Information Request/Reply pair was intended to support self-configuring systems such 
as diskless workstations at boot time, to allow them to discover their network address. 

The sender fills in the request with the Destination IP address In the IP Header set to zero 
(meaning this network). The request may be sent with both Source IP Address and Destination IP 
Address set to zero, The sender initializes the identifier and the sequence number, both used to 
match the replies with the requests, and sends out the request The ICMP header code field is 
zero. 

If the request was Issued with a non-2ero Source IP Address the reply would only contain the 
network address in the Source IP Address of the reply, H the request had both the Source IP 
Address and the Destination IP Address set to zero, the reply will contain the network address In 
both the source and destination fields of the IP header. 

From the description above one can understand that the ICMP Information request and reply 
mechanism was Intended to be used locally. 



The RARP f BOOTP & DHCP protocols provide better mechanisms for hosts to discover its own 
IP address. 



11 lunpush was written ty stayer of h»spahaek .http^/hkpanacl<.cec.dg; . 
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A more accurate table that fists which operating systems would answer to an ICMP ECHO 
request aimed at their Network / Broadcast address is given below: 



Operating System 


Echo Rddtiest 
Broadcast 


DeNan GNU/ LINUX Kernel 2.4 test 2 
Redhat LINUX Kamel 2.2.14 


+ 
+ 


FroeBSD 4.0 
FreeBSD 3.4 
OpenBSD 2.7 
OpenBSD 2.6 
NetDGD 




$olarfe 2.5.1 
Solaris 2.6 
Solaris 2.7 
Solan's 2,8 


+. 
<* 
+ 
+ 


HP-UX vt 0.20 




AIX 




ULTRlX 




Windows 95 
Windows 98 
Windows 98 Se 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Wfodows NT 4 Server SP4 
Windows 200o Profasstona! (and SP1) 
Windows 2000 Sctfvar (and SP1 ) 





Table 1: Which Operating Systems would answer to an ICMP ECHO Request aimed at the Broadcast 

Address of the Network they reside on? 



Counter-measure: Block the IP directed broadcast on the border router. 



2.4 Non-ECHO ICMP 

ICMP ECHO Is not the only ICMP query message type.avallaWe with the ICMP protocol. 

Non-ECMO ICMP messages are being used for more advanced ICMP scanning techniques (not 
only probing hosts, but network devices, such as a router, as well). 

The group of ICMP query message types Includes the following: 

ECHO Request (Type 8) r and Reply (Type 0) 

Time Stamp Request (Type 13), and Reply (Type 14) 

Information Request (Type 15), and Reply (Type 16) 

Address Mask Request (Type 1 7), and Reply (Type 1 6) 

Router Solicitation (Type 10), and Router Advertisement (Type 9) 



14 
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2.4.1 ICMP Time Stamp Request (Type 13) and Reply (Type 14) 

The ICMP Time Stamp Request and Reply allows a node to query another for the current time. 
This allows a sender to determine the amount of latency that a particular network is experiencing. 
The sender Initiates the Identifier (used to identify Timestamp requests aimed at different 
destination hosts) and sequence number (if multiple Timestamp requests are sent to the same 
destination host), sets the originate time stamp and sends It to the recipient. 

The receiving host fills In the receive and transmit time stamps, change the type of the message, 
fo time stamp reply and returns It to the recipient The lime stamp Is the number of milliseconds 
elapsed since midnight UT (GMT). 

The originate time stamp is the time the sender last touched the message before sending it, the 
receive time stamp is the time the recipient first touched it on receipt, and the Transmit time 
stamp Is the time the receiver last touched the message on sending it. 



16 



31 



Cote 



ChaJourn 



SsqcBtft Number 



Figure 4: ICMP Time Stamp Request & Reply message format 



As RFC 1122 state, a host may Implement Timestamp and Timestamp Reply. If they are 
Implemented a host must follow this rules: 

o Minimum variability delay in handling the Timestamp request, 
o The receiving host must answer to every Timestamp request that he receives, 
o An ICMP Timestamp Request to an IP Broadcast or IP Multicast address may be silently 
discarded. 

o The IP source address In an ICMP Timestamp reply must be the same as the specific- 
destination address of the corresponding Timestamp request message- 

o If a source-route option is received in a Timestamp request, the return route must be 
reserved and used as a Source Route option for the Timestamp Reply option* 

o If a Record Route and/or Timestamp option is received in a Timestamp request, this 
option(s) should be updated to include the current host and included In the IP header of 
the Timestamp Reply message. 



Receiving an ICMP Timestamp Reply would reveal an aBve host (or a networking device) that has 
implemented the ICMP Timestamp messages, 
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In the next example I have sent an ICMP Time Stamp Request, using the icmpush 11 tool, to a 
Redhat 6.1 LINUX, Kernel 2.2.12 machine: 

[tootQstan /rootl# icmpueh -tetamp 192,16B.5.5 
keany.sya-security.com -> 13:48:07 



Snort Trace: 

Ql/2S-13z51;29. 342647 152.16B.5_1 -> 192.1SQ.5.5 
ICMP TTLt254 TOS : 0x0 ID?13170 
TIMES TAMP REQUEST 

88 16 DB D9 02 OB 63 3D 00 00 00 00 00 00 00 00 

01/36-13 .51.29. 342805 192,168.5,5 -> 192.16B.5.1 
ICMP TTL.255 TOScOxO ID: 6096 
TIMESTAMP REPLY 

03 16 D8 D9 02 QB 63 3D 02 B0 50 18 02 SB 50 IB 
2A DE 1C 00 AO F9 * 



When I have sent an ICMP Time Stamp Request to a Windows NT WRKS 4.0 SP4 machine, I got 
no reply. Again, this is not an abnormal behavior from the Microsoft Windows NT machine, lust an 
Implementation choice as RFC 1122 states. 

Counterrneasure: Block ICMP Time Stamp Requests coming from the Internet on the border 
Router and/or Firewall. 

2.4.2 ICMP Information Request (Type 15) and Reply (Typo 16) 

The ICMP Information Request/Reply pair was intended to support self-configuring systems such 
as diskless workstations at boot time, to allow them to discover their network address. 

The sender fills in the request with the Destination JP address In the IP Header set to zero 
(meaning this network). The request may be sent with both Source IP Address and Destination JP 
Address set to zero. The sender initializes the identifier and the sequence number, both used to 
match the replies with the requests, and sends out the request. The ICMP header code field Is 
zero. 

If the request was Issued with a non-zero Source |p Address the reply would only contain the 
network address In the Source IP Address of the reply. If the request had both the Source IP 
Address and the Destination IP Address set to zero, the reply will contain the network address in 
both the source and destination fields of the IP header. 

From the description above one can understand that the ICMP Information request and reply 
mechanism was Intended to be used locally. 



The RARP, BOOTP & DHCP protocols provide better mechanisms for hosts to discover its own 
IP address. 



Icmpush was written hy Stayer of hlsoahack htto^/hispahack.eee.da; . 
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0 4 8 16 31 



Typ* 




Checksum 


Idonllner 


Sequence Number 



Figure S: ICMP Information Request & Reply message format 



The Information Request & Reply mechanism is now obsolete as stated In RFC 1 122, and RFC 
1812 2 , A router should not originate or respond to these messages; A host should riot Implement 
these messages. 

Demands on one hand and reality on the other. 

RFC 792 specifies that the Destination IP address should be set to zero, this mean that hosts that 
do not reside on the same network cannot send these ICMP query type. 

But what would happen if we would send an ICMP Information Request with the Destination IP 
address set to a specific IP address of a host out in the void? 

The next example Illustrates that some operating systems would answer these queries even if not 
Issued from the same network. The [CMP Information Request queries we are sending are not 
really RFC compliant because of the difference in the Destination IP address. 

Those operating systems that answer our queries work In contrast to the RFC guidelines as well. 
We would see in the next example why. 

In the next example I have sent an ICMP Information Request, using the SING 13 tool, to an AIX 
machine; 

[3:oot®aik icmp]# ./sing -info hoet^address 14 
SINGing to host_ad3reee {ip__address) r 8 data bytes 
8 bytes from ip_a<3dre&S: icmpseqaO ttl=*238 Info Reply 
■ft bytes from ip__addxeas : icmp_seq=x ttl^238 Info Reply 
6 bytes from ipaddreae: iC7ftp ; _eeq-2 ttl=23B Info Reply 
8 bytes from ip_address: icmp_Beq=3 Info Reply 

- — hoex_address sing statistics — 

5 packets transmitted, 4 packets received, 20* packet loss 



The tepdump trace: 

19:56 = 37,543675 pppO > x.x.x.x > y.y.y.y ; icmp r info* rroat ion readiest 

4500 OOlc 3372 000O ffOl 18a7 xxxx xxxx 

yyyy yyyy of oo bee3 321c 0000 
19: 56 1 38, 4 61427 pppO < y-y-y-y > x.x.x.x; icnnp: information reply 

4500 001c 66lb 0000 eeOl ffifd yyyy yyyy 



RFC 1 B12: Requirements for IP Version A Routers, http://w^jatf.oro^rfc/rfcl 81 2,txt . As the RFC states this 
mechanism is now obsolete - A minor should not originate or respond 10 those messages; A host should not Implement 
these messages. 

SING written by Alfredo Andres Ometla, can be found at http:;/5oun»foTqe.net/ofo|ecls/slna 
Since I have queried a production system for thfe test, with a permission of the owners, I do not wish to Identify It 
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3»ocx X3QOC lOOO ^3 321C OOOO 



Lets do a quick analysis of the trace. 
The ICMP Information Request 



value . 


•Raw V .. 


Additional Information 


4 
5 
00 

001c 

oooo 
ff 

01 

1Ba7 

8b5cti0.15 

or 

00 

bo 63 
321c 
0000 


inversion 

4-mt Header Length 

B-BHTOS 

1Mlt Total Length 

16 Bit Identification 

3-BH F1a$a + 13-Wt Fragment Offset 

B-BHTTL 

8-Bit Protocol 

16-BltHeadflr Checksum 

32-bft Source IP Address 

32-Bft Destination IP Address 

8-BltType 

a-eii code 

16-BM Checksum 

16^ Identifier 

16-6 ft Sequence Number 


IP Version 4 

4 x DWORD = 20 Bytes 

TOS=0 

TTL=255 

i=icmp 

- 130.92.208.21 

Type=15 
Code=0 



The ICMP Information Reply; 



Value 


Field - 7 y ' 


Additional Information • 


4 

S 

00 

00 1C 
66 1b 
00 00 
ee 
01 

F6fd 

XX XX XX XX 

8b 6c do 15 

10 

00 

bds3 
321c 
00 00 


4-Bft Vera Ion 

4- BM Header Length 
8-BltTOS 

16-Bit Total Length 
18~Bit IdenUflcaUon 
3-Bit Rags + 13-blt Fragment Offset 

5- BUTTL 
s-Blt Protocol 

16-Bit Header Checksum 
324& Source IP Address . 
32-BR Destination IP Address 
8-Bit Type, 

8-BitCode 
16-Bk Checksum 

1*eit Identifier I 
16-Plt Sequence Number < 


IP version 4 

4 x DWORD = 20 Bytes 

TOS=0 

TTL=23S 

1=ICMP | 

139.92.20B.21 

Type=16 

Cftde=0 



Instead of having the network address in the Source IP Address we are getting the IP address of 
the host 

Does the reply compliant with RFC 792 regarding this Issue? Basically yes, because the RFC 
does not specify an accurate behavior. 

The RFC states: 'To form a information reply message, the source and destination addresses are 
simply reversed, the type code chanoes to 16, and the checksum recomputed'. 
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This means that if the ICMP Information Request Is coming from outside (Destination Is not zero) 
of the network in question, the network address would not be revealed. But still a host could be 
revealed if he answers the request 

The request Is not compliant with the RFC in my opinion because it does not fulfill its job - getting 
the network address. \ 

Countermeasure: Block ICMP Information Requests coming from the Internet on the border 
Router and/or Firewall* 

2.4.3 ICMP Address Mask Request (Type 17) and Reply (Type 18) 

The ICMP Address Mask Request (and Reply) fs Intended for diskless systems to obtain its 
subnet mask in use on the local network at bootstrap time- Address Mask request is also used 
when a node wants to know the address mask of an Interface. The reply (if any) contains the 
mask of that interface. 

Once a host has obtained an IP address, it could than send an Address Mask request message 
to the broadcast address of the network they reside on (255.255.255.255)* Any host on the 
network that has been configured to send address mask replies will fill in the subnet mask, 
change the type of the message to address mask reply and return it to the sender, 

RFC 1122 States that the Address Mask request & reply query messages are entirely optional. 



o 4 a 16 





Cods 


Chdoun 




fir 


SeqjHTpaNuTiba' 


SiirSi edttass mode 



Figure 6: ICMP Address Mask Request & Reply message format 



RFC 1 122 also states that a system that has implemented ICMP Address Mask messages must 
not send an Address Mask Reply unless it is an authoritative agent for address masks. 

Usually an Address Mask request would be answered by a gateway. 

Receiving an Address Mask Reply from a host would reveal an alive host that Is an authoritative 
agent for address masks, it will also allow a malicious computer attacker to gain knowledge about 
your network's configuration. This information can assist the malicious computer attacker in 
determining your internal network structure, as well as the routing scheme. 

Please note that a Router must implement ICMP Address Mask messages. This will help Identify 
routers along the path to the targeted network (It can also reveal Internal routers if this kind of 
traffic Is allowed to reach them). 

If the Router Is following RFC 1812 closely, it should not forward on an Address Mask Request to 
another network. 
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ICMP Address Mask Request aimed at a LINUX machine would not trigger an ICMP Address 
Mask Reply, nor a request aimed at a Microsoft Windows NT 4 Workstation Sp 6a box. 

In the next example I have sent an ICMP Address Mask Request to the broadcast address 
(192.168.5.255) of a class C network 192.168.5.0, spoofing the source JP to be 192.1 68.5.3: 

[rootaatan /root]# icmpush -w -mask -Sp 192. 168 ,5. 3 1S2 . 168 . 5 . 255 

-> ICMP total size ■ 12 bytes 

-> Outgoing interface =192.168.5*1 
. -> MTU - 1500 bytes 

-> Total packet size (ICMP + IP) « 32 bytes 
ICMP Address Mask Request packet sent to 192.168 .5.255 (192.168.5.255) 

Receiving ICMP replies . . . 



192*168.5.3 ... 

Type <= Address Mask Request (0x11) 
Code * 0x0 Checksum = 0xBFB7 
Id o 0x3B7 Seq# « 0x3 CBO 

icmpush: Program finished OK 



The snort trace: 
-*> snort i <*- 

Version 1-5 

By Martin Roeech (roeach@clark.net, vww.clark.net/-roeschy 
Kernel filter, protocol ALL,, raw packet socket 
Decoding Ethernet on interface ethO 

02/lS-13:4?;37. 179276 132,168.5.3 -> 192.168.5.255 
ICMP TTLt254 TOS;0x0 ID: 13170 
ADDRESS REQUEST 

B9 03 8E 49 00 00 00 00 ...I 



No answer was received from the LINUX machines or from the Microsoft Windows NT 
Workstation 4 SP 6a machine on our test lab. 

When I have tried to map which operating systems would answer {If at all) the ICMP Address 
Mask Requests, I have discovered that SUN Solaris Is very cooperative with this kind of query 15 : 

[rootoaik icmp]# ./sing -mask -c l iP^Addresa 16 

SIHGing to IP_Address (IP_Address) : 12 data bytes 

12 bytes from I*_Addresa: icmp_seq-0 ttl-241 tnask±»255.255.255 .0 

lP_Address sing statistics — - 
l packets transmitfcad, X packets received, 0% packet loss 
[root®aik icmp]# 



The Tcpdump trace: 



The -c 1 option enable SING to send only on* ICMP datagram. TTib parameter can be charmed to any desired value. 

The real IP Address and the Host address were replaced. 
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20:02:07.402229 pppo > x.x.x.x > y,y.y.y: icmp 5 address mask request 

4500 0020 3372 0000 ffOl 70a7 xxxx xxxx 

yyyy yyyy noo afe3 3fic oooo oooo oooo 
20:02:07.831426 pppO < y.y.y.y > x.x.x.x: icmp: address mask is 
OxffffffOO (DF) 

450o 0020 3617 4000 fioi 3co2 yyyy yyyy 

xxxx XXXX 1200 afe2 3fla 0000 ff£f ff00 



Our two last examples would be an ICMP Address Mask request aimed at a muter (which must 
Implement ICMP Address Mask Messages) and at a switch. 

The following is an Address Mask Request sent to a Cisco Catalyst 5505 with OSS v4,5; 

inferno r/tmp# sing -mask -c 1 10. 13. SB. 240 
SlHGing to 10,13*58.240 (10,13*58.240): 12 data bytes 
.12 bytes from. 10.13.58*240: icmp_seq»0 ttl=60 mask=255 . 255 . 255 . 0 

10. 13. 5B. 240 sing statistics 

1 packets transmitted, 1 packets received, 0% packet loss 
inremo:/tmp# 

inferno: -# tcpdump -tnxv -s 1600 icmp 
tcpdurap; listening on xlO 

10. 13.58. 199 > 10.13.58,240? icmp: address mask request {ttl 255, id 
13170) 

0000 : 4500 0020 3372 0000 PP01 FE95 0A0D 3AC7 E . . 3r 

0010 ; 0A0D 3AFQ 1100 6BF7 8308 0000 0000 0000 . . : k , , , ... 

10,13.58.240 > 10. 13.58. 199= icmp: address mask is OxffffffOO (ttl 50, 
id 20187) 

0000 : 4500 0020 4EDB 0000 3C01 A631 0A0D 3AF0 E . . N <..l.,-. 

0010 : 0A0D 3AC7 1200 GBF6 ' 830B 0000 FFFF FF0O ,k 

0020 : 0000 0000 0000 0000 0000 0000 0000 
*C 

79 packets received by filter 
0 packets dropped by kernel 
inferno : -# 



The last example Is an ICMP Address Mask request sent to an Intel 6100 ISDN Router on our 
network: 

[rootOaik iemp]# ./sing -mask 10,0.0.254 
SXNGing to 10.0.0.254 (10.0.0.254): 12 data bytes 
12 bytes from 10.0.0.254:- iemp_seq^0 ttl~64 mask-255 .255 .255 . 0 
12 bytee from 10.0.0.254: iCmp_Seq=l ttl-64 mask-255. 255. 255.0 
12 bytes from 10. 0.0, 254 t icmp_seq»2 ttl-64 maek=255 .255-255.0 

10.0,0,254 sing statistics 

3 packets transmitted, 3 packets received, 0% packet loss 
[rootQaik icmp]# 

The tcpdump trace: 

2t 
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[rootGaik /roofc]# tcpdump icmp 

Kernel filter, protocol ali*, datagram packet socket 
tcpdump: listening on all devices 

. IS: 34: 3 0.666687 ethO > 10.0.0.105 > 10.0.0.254: icmp : address mask 
request 

4500 0020 3372 0000 ffOl 7304 0a00 0063 
OaOO OOfe 1100 Oafd e402 0000 0000 0000 

16:34:30.667961 ethO < 10.0.0-254 > 10.0.0.105: icmp : address mask is 

OxffffffOO 

4500 0020 2cb7 0000 4001 38c0 OaOO OOfe 
OaOO 0069 1200 Oafc e402 0000 ffff ffOO 
0000 0000 000O 0000 0000 0000 0000 



Counter-measure: Block ICMP Address Mask Requests coming from the Internet on the border 
Router and/or Firewall. 



2.5 Non-ECHO ICMP Sweeps 

We can query multiple hosts using a Non-ECHO ICMP query message type. This Is referred as a 
Non-ECHO ICMP sweep.- 

Who would answer our query? 

Hosts that answer to the following: 

o Hosts that are In a listening state. 

o Hosts running an operating system that implemented the Non-ECHO ICMP query 

message type that was sent 
o Hosts that are configured to reply to the Non-ECHO ICMP query message type (few 

conditions here as well, for example: RFC 1 122 states that a system that Implemented 

ICMP Address Mask messages must not send an Address Mask Reply unless It is an 

authoritative agent for address masks). 



Given the conditions above, which host(s) would answer our queries? 



Dperating System 


Infix R«ru"0St ' 


Tinie Stamp Request 


Address Mask Request 


Deblan GNU/ LINUX 2-2, Kerne] 2.4 test 2 








ftedhat UNUX 6.2 KemBl 2.2.14 








FrwBSD 4.0 




+ 




FreaBSD 3,4 




+ 




OpenBSD 




+ 




NetSSD 








Solaris 2.5.1 




+ 


+ 


Solaris 2.6 




■ + 


+ 


Solaris 2.7 




+ 


+ 


SoferteZS 






+ 


HP-UX vlO.20 




+ 




AJXv4jc 
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; OparalingiSystem '"• 


■ Info. Request 


Jlnte Starnp Request' 


Addrees Mask Request 


ULTRIX4,2-4,5 


+ 


+ 




Windows 95 








Windows 08 








Windows 93 SE 






+ 


Windows ME 




+ 




Windows NT 4 WRKS SP 3 








Windows NT 4 WRKS SP 6a 








Windows NT 4 Server SP 4 








Windows 20QO Professional 




+ 




.Windows 2000 Server 









Networking fiovlciafi ; " ' \ - 


Infapj&ijgest 


Tfrne Stamp Request" 


Address Mask Requestj/ . 

. • ; - "'"V ; "e«_ 


Cisco Catalyst 5505 with OSS v4.5 


+ 


+ 


+ 


Cisco Catalyst 29O0XL wfth IOS 1 1 .2 




+ 




Cisco 3600 with JOS 11.2 








Cisco 7200 wllh IOS 11,3 








Intel Express $10o ISDN RoutBr 






+ 



Table 2: non-ECHO ICMP Query of different Operating Systems and Networking Devices 



Countermeasura: Block ICMP Information Requests, ICMP Address Mask Requests & ICMP 
Time Stamp Requests coming from the Internet on the border Router and/or Firewall. 

2.6 Non-ECHO ICMP Broadcasts 

We can send a Non-ECHO ICMP query message type to the broadcast address or to the network 
address of the targeted network. 

The request would be broadcasted to all listening hosts on the targeted network. 
Who would answer pur query? 

o Hosts that are In a listening state 

o Hosts running an operating system that implemented the Non-ECHO ICMP query 
message type that was sent 

o Hosts that are configured to reply to the Non-ECHO ICMP query message type (few 
conditions here as well, for example: a host may discard Non-ECHO ICMP query 
message type requests targeted at the broadcast address. For example an ICMP 
Timestamp Request to an IP Broadcast or IP Multicast address may be silently 
discarded). 



Given the conditions above, the answering hosts would almost always be UNIX and UNIX-like 
machines. SUN Solaris, HP-UX, arid LINUX are the only operating systems, from the group of 
operating systems I have tested, that would answer to an ICMP Timestamp Request aimed at the 
broadcast address of a network. HP-UX would answer Information Requests aimed at the 
broadcast address of a network. Non-would answer to an ICMP Address Mask Request aimed at 
the broadcast address of a network. 
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Operating System ■ [ 




jlme Siair^flje^sst 


Address Mask Request 


\- • ■ .. ft . s >,., ■»,...••'. 


• Brpadcastv 1 . 


! prdadcast 


Broadcast " ;-. 


Dabfan GNU/ UNUX 2J2, Kernel 2.4 test 2 
Kednat UNUX 8.2 Kernel 


- 


+ 

•* 


— — ™ 


FroaBSD 4.0 
Free BSD 3.4 
OpenBSD 2.7 
OpenBSO 2.6 
NetBSD 






j 


Solaris 2.5.1 
Solans 2.6 
Solans 2.7 
Solaris 2,3 


* 
• 


+ 




HP-UX vl 0.20 


+ 


+ 




AJX4* . 








ULTRIX4.2-.4.5 








Windows 95 
Windows 98 
Window 90 SE 
Windows ME 

Windows NT 4 WRKS SP 3 
Windows NT 4 WRKS SP 6a 
Windows NT 4 Server SP 4 
Windows 2000 Professional (& SP1 ) 
Windows 2000 Server (& SP1) 








Table 3: Operating Systems, which would answer to requests, aimed at the Broadcast address 


Networking Devices ' 


. Into, fioo^est 


• TirriO Stamp Re0^le3t ■ 


Address Mask Request 






Broadcast.. \ 


Broadcast 


Cisco Catalyst 5505 with OSS v4.5 
CIscoCatalyst28O0XL with IOS 11,2 


+ 


+ 




Cisco 3600 wilh IOS 11.2 
Cisco 7200 with IOS 11.3 








Intel Express 8100 ISDN Router 









Table 4: Networking Devices, which would answer to requests, aimed at the Broadcast address 



Countermeasure: Block the IP directed broadcast on the border router. Block ICMP Information 
Requests, ICMP Address Mask Requests & ICMP Time Stamp Requests coming from the 
Internet on the border Router and/or Firewall. 
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3-0 Advanced Host Detection using the ICMP Protocol (using ICMP Error 
Messages generated from the probed machines) 

The advanced host detection methods rely on the idea that we can use various methods In order 
to elicit an ICMP Error Message back from a probed machine and discover Its existence. Some of 
the methods described here are: 

• Mangling IP headers 

o Header Length Field 
o IP Options Field 
Using non-valid field values In the IP header 

o Using valid field values in the IP header 

• Abusing Fragmentation 

• The udp Scan Host Detection method 

with the first method we are using bad IP headers in the IP datagram that would generate an 
ICMP Parameter Problem error back from the probed machine to the source IP address of the 
probing datagram. The second method use non-valid field values in the. IP header in order to . 
force the probed machine to generate ICMP Destination Unreachable error message back to the 
malicious computer attacker. The third method discussed uses fragmentation to trigger an ICMP 
Fragment Reassembly Time Exceeded error message from the probed machine. The last method 
uses the UDP Scan method to elicit ICMP Port Unreachable error message back from a closed 
UDP port(s) on the probed host(s). 

When using some of those methods we can determine if a filtering device is present and some 
can even discover the Access Control List a Filtering Device is forcing on the protected network. 



0 4 8 tO 31 



4tl ** 


(TOS)"0 












(TTL) 


OCMP) 






tttt ttasttatfan IP Bkkm 







2Qtytm 



Figure 7; The IP Header 



3.1 Sending IP Datagrams with bad IP headers fields -generating ICMP Parameter 
Problem error message back from probed machines 

An ICMP Parameter Problem error message Is sent when a router (must generate this message) 
or a host {should generate this message) process a datagram and finds a problem with the IP 
header parameters, which Is not specifically covered by another ICMP error message. The ICMP 
Parameter problem error message Is only sent if the error caused the datagram to be discarded. 

We have some variants with this type of Host Detection. We send an illegal forged datagram (s) 
with bad IP header fleWfs), that no specific ICMP error message is sent for this fle)d(s). It will 

25 

Copyright © Ofir ArkJn, 200Q-2QCH 

hUp;//w^-£yfi : sQcurltv.com 



PAGE 78/209* RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylp Time] * SVR:USPTO-EFXRF-2/2 * DNIS:7469694 1 CSID : 9497609502 * DURATION (mm-ss):5746 



Jun-30-2004 09:22pm Frora-KNOBBE MARTENS OLSON BEAR 949 7609502 T-702 P. 079/1 04 F- 

Q ■ O 

JCMP Usage In Scanning 
Version^ 

force a Host to send back an ICMP Parameter Problem Error message with either Code 0 or 
Code 2 (When code 0 is used, the pointer field will point to the exact byte in the original IP 
Header, which caused the problem. Code 2 te sent when the Header length or the total packet 
length values of the IP datagram do not appear to be accurate) to the source IP address Of the 
bad IP datagram and reveal its existence. With this type of host detection It fs not relevant what 
would be the protocol (TCP/UDP/1CMP) embedded inside the IP datagram. All we care about is 
the ICMP Error messages generated by the probed machine (if any). 

This method is very powerful in detecting host(s) on the probed network with direct access from 
the Internet, since a host should generate this error message. Routers must generate the ICMP 
Parameter Problem error message as well, but not all of them check the correctness of some 
fields Inside the IP header like a host does (processing of some fields is done on the host only). 

According to RFC 1 122 a host should chBck for validity of the following fields when processing a 
packet 17 ; 

• Version Number - If not 4 a host must silently discard the IP packet. 

• Checksum - a host should verify the IP header checksum on every received datagram 
and silently discard every datagram that has a bad checksum, 

A router should check for the validity of the following fields when processing a packet 18 : 

• Checksum - a router must verify the IP checksum of any packet it received, and must 
discard messages containing Invalid checksums. 

> 

The conditions outlined eliminate the usage of this method to a limited number of fields only. 

It is possible to send an IP datagram with bad ffefd(s) in the IP header, which will get routed 
without getting dropped in the way to the probed machine. It should be noted that different routers 
perform different checks regarding the IP header (different implementation and interpretation of 
RFC 1812), When a router, because of a bad IP header, drops an IP packet and sends an ICMP 
Parameter Probtem error message, it is possible to identify the manufacture of the router, and to 
adjust the wrong IP header flew correctly according to a field, which Is not checked by the 
manufacture of that particular router. 

A router may be more forgiving than a Host regarding the IP header. This may result from the fact ' 
that a router is a vehicle for delivering the IP datagram and a Host is the Destination and the 
place where more processing on the datagram is done. 

The downside for this method is the detection. Intrusion Detection Systems should alert you 
about abnormalities in the attacked network traffic, since not every day you receive IP packets 
with bad IP Header fleld(s). 

We can use this type of Host Detection to sweep through the entire IP range of an organization 
and get back results, which will map all the alive hosts on the probed network with direct access 
from the Internet 

Even If a firewall or another filtering device is protecting the probed network we can still try to 
send those forged packets to an IP addresses with ports that are likely to be opened. For 



" RFC 1 122 - Requirements for Internet Host http:// W ww,| e tf.om/rfcfrfc1 122.t*t 
RFC 1812 - Requirements far IPv4 Routers. httD-y/wwwj6tf.nr<!i/rfc/rffclSl$.txt. 
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example - TCP ports 21,25,80; UDP port 53; and even try to send an ICMP message presumably 
coming back from a Host/Router who generated It upon receiving data from the attacked network* 

In my opinion Firewalls/Riterfng Devices should check the validity of those fields used to elicit the 
ICMP Parameter Problem error message and disallow this kind of traffic. 

An example is given here using the iStC tool written by Mike Frantzen 19 . ISIC sends randomly 
generated packets to a target computer. Its primary uses are to stress test an IP stack, to find 
leaks In a firewall, and to test the implementation of Intrusion Detection Systems end firewalls. 
The user can specify how often the packets will be fragmented; have IP options, TCP options, an 
urgent pointer, etc. 

In the next example I have sent 20 IP Packets from a LINUX machine to a Microsoft Windows NT 
WRKS 4 SP4 machine. The datagrams were not fragmented nor bad IP version numbers were 
sent. The only weird thing sent inside the IP headers was random IP Header length, which have 
produced ICMP Parameter Problem Code 2 error message as I anticipated. 



troot@stan.packetshaping]# ./isic -a 192.168.5 > 5 -d 192.168.5,15 -p 20 

-F 0 -V 0 -I 100 

Compiled against Lionet 1*0 

Installing Signal Handlers. 

Seeding witn 2015 

No Maximum traffic limit er 

Bad IP Version = 0% Odd' IP Header Length * 100% 

Frag 'd Pent ■ 0* 

Wrote 20 packets in 0.03s ft 637.94 pkts/s 



tepdump trace: 

12:11:05.843480 ethO > kenny . sys- security- com > cartman. eys- 
security.com: ip-proto-110 226 [toe 0xe6,ECTJ (tti no, id 119, 
Optlen*24 [ | ip] ) 



12:11:05.843961 CthO P cartman.Sye-security.com > kenny. sys- 
BeCurity.comr icmp: parameter, problem - octet 21 Offending pkts 
kenny. ays -security* com > cartraan.sys-security.com: ip-proto-110 226 
Ctos 0xefi,ECT] (ttl 110, id 119, optlen«24 [ | ip] ) (ttl 128, id 37776) 



Other fields we can use Inside the IP Header 

In the last example we have used a bad Header Length field value to generate an ICMP 
Parameter Problem' code 2-error message. 

An ICMP Parameter Problem would almost always result from an Incorrect usage of the IP option 
field as well, 

3.1.1 ACL Detection using IP Datagrams with bad IP headers fields 
rf we probe the entire IP range of the targeted network with all combinations of protocols and 
ports, it would draw us the targeted network topology map, and will allow us to determine the 
access list (ACL) a Filtering Device (If present, and not Mocking outgoing ICMP Parameter 
Problem Error messages) is forcing. 
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This, if the filtering device does not check the validity of the mangled IP header fields, and allows 
the specified traffic. 



3.1 L1 1 How we determine the ACL (ICMP Protocol embedded Inside)? 
When the embedded protocol is ICMP, we send various ICMP message types encapsulated 
inside IP datagrams with bad IP headers). If we receive a reply from a Destination IP address we 
have a host that is alive and an ACL, which allows this type or message of ICMP to get to the 
host who generated the ICMP error message (and the Parameter Problem ICMP error message, 
is allowed from the destination host to the Internet). 

If we are not getting any reply than one of three possibilities: 

• The Filtering Device disallows datagrams with the kind of bad field we are using. 

* The Filtering Device is filtering the type of the ICMP message we are using. 

» The Filtering Device blocks ICMP Parameter Problem error messages initiated from the 
protected network destined to the Internet 




3.1.1.2 How we determine the ACL (TCP or UDP Protocol embedded inside)? 
We can probe for every combination of protocol and port values inside an IP packet with bad IP 
header(s). tf we woufd receive an answer it would indicate that the protocol and port we used are 
allowed to the probed host from the Internet, and the ICMP Parameter Problem error message is 
allowed from the destination host in the protected network out to the Internet It would also 
indicate that the filtering device used on the targeted network is not validating the correctness of 
the fields we have used in order to elicit the ICMP Parameter Problem error message. 

If the embedded protocol were either TCP or UDP, a reply would not be generated if: 

• The Filtering Device disallows packets with the kind of bad field we are using. 

• The Filtering Device filters the Protocol used. 

• The Filtering Device is filtering the specific port we are using for the probe. 

• The Filtering Device blocks ICMP Parameter Problem error messages Initiated from the 
protected network destined to the Internet In our case, the filtering device may be 
blocking the specific host we are probing for outgoing ICMP Parameter Problem 
datagrams. 

Note : If we are using the IP Header Length field in order to elicit ICMP Parameter Problem error 
message back from the probed host(s) than the host processing the datagram may not be able to 
access the Protocol Information embedded inside. The reason would be the faulty calculation that 
would be made - where the header ends and the data portion begins. 



Countermeasure: Block outgoing ICMP Parameter Problem from the protected network to the 
Internet on the Firewall & on the border Router. 

Check with the manufacture of your filtering device which fields it validates on the IP header when 
processing a datagram. 
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3JZ IP Datagrams with non-valid Held values 

This Host Detection method is based on different IP header fields within the crafted IP datagram 
that would have npn-valld field values, which would trigger an ICMP Destination Unreachable 
Error message back from the probed machines. 

Note that some hosts (AIX, HP-UX, Digital UNIX) may not send ICMP Protocol Unreachable 
messages. 

3,2.1 The Protocol Field example 

3.n:i Using non-Valid (not used) IP protocol values 

One such field Within the IP header is the protocol field. If we wiH put a value, which does not 
represent a valid protocol number, the probed machine would elicit an ICMP Destination 
Unreachable - Protocol Unreachable error message back to the.probed machine. 

By sending this kind of crafted packets to all IP addresses within the IP address range of the 
probed network we can map the hosts that are directly connected to the Internet {assuming that 
no filtering device is present, or filtering the specific traffic). 

3,2,1-1-1 Detecting If a Filtering Device Is present 

A packet sent with a protocol value, which does not represent a valid protocol number, should 
elicit an ICMP Destination Unreachable -Protocol Unreachable from the probed machine, Since 
this value is not used (and not valid) an hosts probed, unless filtered or are AIX, HP-UX, Digital 
UNIX machines, should send this reply. If a reply is not received we can assume that a filtering 
device prevents our packet from reaching our destination or from the reply to reach us back. 



3.2.1.2 Using all combination of the IP protocol filed values 

The difference with this variant Is that we use all of the combinations available for the IP protocol 
field - since the IP protocol field has only 8 bits In length, there could be 258 combinations 
available. 

NMAP 2,54 Beta 1 has integrated this variant and Fyodor have named it - IP Protocol scan. 
NMAP sends raw IP packets without any further protocol header (no payload) to each specified 
protocol on the target machine. If an ICMP Protocol Unreachable error message Is received, the 
protocol Is not In use. Otherwise It is assumed it is opened (or a filtering device Is dropping our 
packets). 

If our goal was Host Detection only, than using the NMAP implementation would be just fine. But 
if we wish to use this scan type for other purposes, such as ACL detection, than we would need 
the payload data as well (the embedded protocol's data). 

We can determine If a filtering device is present quite easily using this scan method. If a large 
number of protocols (non valid values could be among those) seems to be "opened'/used (not 
receiving any reply - ICMP Protocol Unreachable) than we can assume a filtering device is 
blocking our probes (If using a packet with the protocol headers as well). If the filtering device is 
blocking the ICMP Protocol Unreachable error messages Initiated from the protected network 
towards the Internet than nearly all of the 256 possible protocol values would be seemed 
"openedVused. 

With the current implementation with NMAP the 256 possible protocol values should be "opened" 
when a scan Is performed against a machine inside a protected network, because a packet fitter 
firewall (or other kind of firewall) should block the probe since it lacks information to validate the 
traffic against Its rule base (information In the protocol headers such as ports for example). 
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In the next example I have used NMAP 2.54 Beta 1 in order to scan a Microsoft Windows 2000 
Professional machine: 

[root®catman /root] # nraap -w -sO 192.168.1.1 

starting nmap v. 2.54BETA1 by fyodor@insecuxe.org { 
.www . insecure * org/nmap/ ) 

Hoot (192. 168. 1*1) appears to be up ... good. " 
Initiating PIN, NULL, TJDP, or Xmas stealth o can- against {192 .ICS .1-1) 
The HDP or stealth FIN/NULL /XMAS scan took 4 Beconda to scan 254 ports, 
interesting protocols on (192.168.1*3.) = 

(The 250 protocols scanned but not shown below are in state: closed) 



Protocol 


state 


Name 


l 


open 


icmp 


2 


open 


igmp 


6 


open 


top 


17 


open 


udp 



Nmap run completed 1 IP address (1 hOQt up) scanned in 4 seconds 



A tcpdump trace of some of the communication exchanged: 

17:44:45,651855 ethO > localhbst .localdomain > 192. 16ft. 1- Is ip-proto-SO 
0 (ttl 38, id 29363) 

17:44:45.652169 ethO < 192.168.1.1 > localhost .localdomain; icrap: 
192. 168 ,1,1 protocol 50 unreachable Offending pktz 

-localhoat. localdomain > 192, 168. 1-1 i ip-proto-50 0 (ttl 38, id 29363) 
(ttl 128, id 578) 

17:44:45.652431 ethO > localhost . local domain > 192.168-1.1; ip-proto- 
133 0 (ttl 3B. id 18) 

17:44:45.652538 ethO > localhost . localdomain > 192.163.1.1: ip-proto- 
253 0 (ttl 38, id 36169) 

17:44:45.652626 ethO =» localhost .localdomain > 192. 168. 1.1: ip-proto-92 
0 (ttl 38, id 26465) 

17 ;44 ;4S, 652727 ethO c 192.168.1.1 > localhost , local domains icrop ; 
192.168.1.1 protocol 133 unreachable Offending pKt: 

localhost. localdomain > 192.168-1-1= ip-proto-133 0 (ttl 38, id IB) 
(ttl 128, id 579.) 

17:44:45.652760 ethO > localhost . localdomain > 192.168.1.1= ip-proto- 
143 0 (ttl 3B f id 14467) 

17:44:45.652899 ethO > localhost . localdomain > 192.168.1.1: ip-proto-30 
0 (ttl 38, id 30441) 

17;44;45, 652932 ethO < 192.168.1.1 > localhost .localdomain: icmp; 
192. 168. 1.1 protocol 253 unreachable Offending pkt: 

localhost. localdomain > 192.168.1.1: ip-proto-253 0 (ttl 38, id 36169) 
(ttl 128, id 580) 



3.2.2 ACL Detection using the Protocol neld . 

First we need to determine If a filtering device Is present using a non-valid (not used) protocol 
number probe. If a filtering device exists then no answer (ICMP Protocol Unreachable) will be 
received from the probed machine, assuming it Is not ADC, HP-UX or Digital UNIX . 



You can determine this using OS finger printing methods. 
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If a certain protocol were not allowed through the filtering device we would not receive any ICMP 
error message from the probed machine. Probing for all combinations of protocols and parts 
against an IP range of a targeted network using non-valid and valid protocol values can 
determine the ACL a filtering device Is forcing on the protected network, along with the topology 
map of a targeted network (hosts reachable from the Internet). 

A reply would not be generated If: 

• The Filtering Device filters the Protocol we are using 

• The Filtering Device is filtering the specific port we are using for the probe. 

• The Filtering Device blocks ICMP Destination Unreachable - Protocol Unreachable error 
messages initiated from the protected nBtwork destined to the Internet In our case, the 
filtering device may be blocking the specific host we are probing for outgoing ICMP 
Destination Unreachable - Protocol Unreachable error messages. 

Note : We can use this method for ACL detection but if the protocol we are using is not used on 
the target machine it should be blocked on the filtering device. Than, only opened TCP/UDP ports 
and allowed ICMP traffic could traverse the filtering device. If this kind of traffic is allowed we can 
have better ACL detection solutions then we outlined here. 



Countermeasure; Block outgoing ICMP Protocol Unreachable error messages coming from the 
protected network to the Internet on your Firewall and/or Border Router, If you are using a firewall 
check that your firewall block protocols which are not supported (deny all stance). 



3.3 Host Detection using IP fragmentation to elicit Fragment Reassembly Time 
Exceeded ICMP error message. 

When a host receives a fragmented datagram with some of its pieces missing, and does not get 
the missing part(s) within a certain amount of time the host will discard the packet and generate 
an ICMP Fragment Reassembly Time Exceeded error message back to the sending host 

We can use this behavior as a Host Detection method, by sending fragmented datagrams with 
missing fragments to a probed host, and wait for an ICMP Fragment Reassembly Time Exceeded 
error message to be received from a live hostfs), if any. 

When we are using this method against all of the IP range of a probed network, we will discover 
the network topology of that targeted network. 

In the next example I have sent a TCP fragment (with the MF bit set using the -x option with 
hplng2) to a Microsoft Windows ME machine: 



[root^godf ather bin]# hping2 -c l -x -y y*y-y-y 
pppO default routing interface selected (according to /proc) 
hping y-y.y,y (pppo y-y-y-y) = no flags are set, 40 headers + 0 data 

bytes 

— y.y.y,y ixping statistic - — 

1 packets tramitted, 0 packets received, 100% packet loss 
round -trip min/avg/raax » 0*0/0.0/0.0 ma 
[root®godfather bin]# 

The tcpdump trace: 
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2O:20cO<K226O6"4 pppO > x.x.x.x. 1749 > y.y.y'.y.D: - 

1133572879=1133572875(0) win 512 (frag 31927 :20®O+) (DF) (ttl 64) 
4500 0028 7cb7 6000 4006 cSfd XXXX XXXX 
d496 6607 OGdS 0000 4390 f30f 0cl3 6799 
5000 0200 27aS 0000 - 

20:21:00.033205 pppO < y.y-y.y > x.x.x.x: icmp: ip reassembly time 
exceeded Offending pkt: l|tcpj (frag 31927 ;20©D+) (Df) (ttl 55) (ttl 
119, id 12) 

4500 0038 000c 0000 7701 6e9e YYyY YYVY 
xxxx 5QDQC ObOl 1>789 0000 0000 4500 0028 
7cb7 6000 3706 dlfd xxxx xxxx yyyy yyyy 
06dS 0000 4390 £30f 



3*3.1 ACL Detection using IP fragmentation 

This method can be used not only to map the entire topology map of the targeted network* but 
also to determine the ACL a firewall or a filtering device Is forcing on the protected network. 

Simply using all combinations of TCP and UDP with different ports, with the IP addresses from 
the IP range of the probed network wilt do it When we receive a reply It means a host we queried 
Is alive, the port we have used is opened on that host, and the ACL allows the protocol type and 
the port that was used to get to the probed machine (and the ICMP Fragment Reassembly Time 
Exceeded error message back from the probed machine to the Internet). 

If we were not getting any reply back from the probed machine it can mean: 

• The Filtering Device filters the Protocol used, 

• The Filtering Device is filtering the specific port we are using for the probe. 

• The Filtering Device blocks ICMP Fragment Reassembly Time Exceeded error messages 
initiated from the protected network destined to the Internet In our case, the filtering 
device may be blocking the specific host we are probing for outgoing ICMP Parameter 
Problem datagrams. 



3.3.1 .1 An Example with UDP (Filtering Device Detection) 

Since UDP Is a stateless protocol It may be better suited for our needs here. The first datagram 
would be fragmented including enough UDP information In the first fragmented datagram that 
would be enough to verify the packet against a Firewall's Rule base. The second part of the 
datagram would not be sent. It would force any host that gets such a packet to send us back an 
ICMP Fragment Reassembly Time Exceeded error message when the time for reassembly 
exceeds. 

If the port we were using wore an open port, than the ICMP Fragment Reassembly Time 
Exceeded error message would be generated. If the port were closed then an ICMP Port 
Unreachable error message would be produced. 

If a firewall is blocking our probed than no reply would be generated. 

No reply would be an Indication mat traffic to the Host we probed Is filtered. 



3.3.1.2 An example with TCP 

We can divide the first packet of the TCP handshake Into two fragments. We would put enough 
TCP Information in the first packet that would be enough to verify the packet against the Firewall's 
Rule base (this means the port numbers we are using are included in the packet). We will not 
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send the second part of the packet, forcing any host that gets such a packet to send us back an 
ICMP Fragment Reassembly Time Exceeded error message when the time for reassembly 
. exceeds. This would Indicate the host Is accessible by this kind of traffic, which Is allowed using 
the port we have specified as the destination port 21 . 
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*H?U Data 
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12 byte 



Figure 8; An Example: A TCP packet fragmented after only 12 bytes of TCP Information 



if the port we are using Is open, than the ICMP error message would be generated. If the port is 
closed than a TCP RST packet should be sent back. If a filtering device were to block our probes 
than no reply would be generated. No reply would be an Indication that traffic to the host we 
probed Is filtered or the filtering device requires that the first TCP packet would not bo fragmented 
(which Is a legitimate requirement). 



3.3.1.3 An Example with ICMP 

We can do the same with encapsulating the ICMP protocol. When doing so the ICMP fragmented 
packets should sound the sirens when an Intrusion Detection system (if deployed) sees them. 
There is no reason to fragment an ICMP datagram* 

If we think of sending fragmented ICMP through a bad filtering device product than we should at 
least Include the first 4 bytes of the ICMP header with the IP datagram, 



Countermeasure: Block outgoing ICMP Fragment Reassembly Time Exceeded Error messages. 



3.4 Host Detection using UDP Scans, or why ws wait for the ICMP Port 
Unreachable 

How can we determine If a host is alive using a UDP probe? - We use the UDP scan method that 
uses ICMP Port Unreachable error message that may be generated from probed hosts as 
indicator of alive hosts. With this method we are sending a UDP datagram with 0 bytes of data to 
a UDP port on the attacked machine. If we have sent the datagram to a closed UDP port we will 



21 hi a caso were a firewall Is validating that the first packet fe not fragmented, we can fragment another one Instead. But 
than this scanning method would not be any different from any othor scanning method using TCP flags combinations. 

33 

Copyright © Ofir Arkln. 2000^2001 
jT^^/www.sve-sacunty.com 



PAGE 86/209 * RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylight Time]' SVR:USPT0-EFXRF-2I2" DNIS:7469694 • CSID:9497609502 ■ DURATION (mm-ss):5746 



Jun-30-2004 09:25pm From-KNQBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P. 087/1 04 F-609 



o 

ICMP Usage In Scanning 
Version 2,5 

receive an ICMP Port Unreachable error message. If the port Is opened, we would not receive 
any reply* x 

When a filtering device is blocking UDP traffic aimed at the attacked machine, it would' copycat 
the behavior pattern as with opened UDP ports. 

If we probe a large number of UDP ports on the same host and we do not receive a reply from a 
large number of ports, it would look like that a large number of probed UDP ports are opened. 
While a filtering device is probably blocking the traffic and nearly all of the ports are dosed. 

How can we remedy this? 

We can set a threshold number of non-answering UDP ports, when reached we will assume a 
filtering device is blocking our probes. 

Fyodor has implemented a threshold with NMAP Z3 BETA 13, so when doing a UDP scan and 
not receiving an answer from a certain number of portSi it would assume a filtering device Is 
monitoring the traffic, rather than reporting those ports as opened. 




3A1 A Better Host" Detection Using UDP Scan 

We will take the UDP scan method end tweak it a bit for our needs. We know that a closed UDP 
port will generate an ICMP Port Unreachable error message indicating the state of the port- 
dosed UDP port. We will choose a UDP port that should be definitely closed (according to the 
IANA list of assigned ports ftp^/ftoJsl.eduAn^otes/iana/asslQnment&/ix>r t-numbemV For example 
we can use port 0 (but it would reveal our probe pretty easily). 

Based on the fact that sending a UDP datagram to a closed port should elicit an ICMP Port 
Unreachable, we would send one datagram to the port we have chosen, than; 

» If no filtering device Is present we will receive an ICMP Port Unreachable error 
message, which will Indicate that the Host is alive (or if this traffic is allowed by 
the filtering device). 

• If no answer Is given - a filtering device is covering that port 

In the next example ! have used the HPING2 22 tool to send one UDP datagram to host 
192.168.5.5 port 50, which was closed: 

[rootfcatan /root] # hping2 -2 192,16B.5.5 -p 50 -c 1 
default routing not present 

HPING 192.168,5.5 (ethO 192 . 16B . 5 . 5) : udp mode set, 28 headers + 0 data 
bytes 

ICMP Port Unreachable from 192.168.5.5 (3cenny.aya-security.com) 
192.168.5.5 hping statistic 

1 packets traraitted, 0 packets received, 100% packet loss 
round- trip min/avg/max =» 0.0/0.0/0.0 ms 



-*> Snort I <+- 
Version 1.5 

By Martin Roesch (roesch®clark.net, www.clark.net/-roesch) 
Kernel filter, protocol AIiL, raw packet socket 



HPING2 written by anlfrez. httD^/wyw-kvuzaLoro/antlroz/hDlncT/ . 
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Decoding Ethernet on. interface etho 
03/12-12; 54:47. 274096 192.168.5.1:2420 
UDP TTL:64 TOS:0*0 JP:57254 
Lea; 6 



-> 192.1^8.5.5:50 



03/12-12:54:47.274360 192,168-5.5 -> 192.168.5-1 
ICMP TTL:25S TOS:0xC0 ID:0 

DESTINATION UNREACHABLE: PORT UNREACHABLE 

00 00 00 00 45 00 QO 1C DP A6 00 00 40 11 OP D4 B ®- , . 

CO A8 05 01 CO A8 05 05 09 74 00 32 00 08 6A El ,.t.2..j. 



We can use the port number we have chosen, or a list of UDP ports that are likely not being used, 
and query alt the IP range of an attacked network. Getting a reply back would reveal a live host 
No reply would mean a filtering device Is covering those hosts UDP traffic, and probably other 
protocols and hosts as well. 



3.5 Using Packets bigger than the PMTU of internal routers to elicit an ICMP 
Fragmentation Needed and Don't Fragment Bit was Set (configuration problem) 
If Internal routers have a PMTU that Is smaller than the PMTU for a path going through the border 
router, those routers would elicit an ICMP "Fragmentation Needed and Don't Fragment Bit was 
Set" error message back to the Initiating host if receiving a packet too big to process that has the 
Don't Fragment Bit set on the IP Header, discovering internal architecture of the router 
deployment of the attacked network. 

This is in my opinion a configuration problem causing a security hazard. , 



77i b htemet 




A configuration Error example. If internal 
Routers are configured with max. MTU 
smaller than the tmx. MTU the border 

router is using, sending packets with the 
Dent Fragrmnt bit set that are small 

enough to pass the border router but are 

bigger than the MTU on an Internal Router 
would reveal those Router's existence. 




Figure 9: Using Packets bigger then the PMTU of Internal routers to elicit an ICMP 
Fragmentation Needed and Dont Fragment Bit was Set * 
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4,0 Inverse Mapping 

Inverse Mapping Is a technique used to map internal networks or hosts that are protected by a 
filtering devices/firewall* Usually sorhe of those systems are not reachable from the Internet. We 
use routers. Which will give away Internal architecture Information of a network, even If the 
question they were asked does not make any sense, for this scanning type. We compile a list of 
IP's that list what Is not there, end use It to conclude were things probably are. 



We send a number of packets to different IP's we suspect are In the IP range of the network we 
are probing. When a router, either an exterior or interior, gets those packets for further 
processing, It looks at the IP address and makes decisions of routing based on it solely. When a 
router gets a packets with an IP which Is not used In the IP space / network segment of the part of 
the probed network he serves, the router will elicit an ICMP Host Unreachable (Generated by a 
router if a route to the destination host on a directly connected network is not available - the 
destination host does not respond to ARP) or ICMP Time Exceeded error message(s) back to the 
originator of the datagram. If we do not get an answer about a certain IP we can assume this IP 
exist inside the probed network 29 . 



4.1 Inverse Mapping Using ICMP (Echo & Echo Reply) 

Theoretically speaking, using any ICMP Query Message type or any ICMP Query Reply Message 
type In order to Inverse map a network using a Router is possible. 

With the next example I have sent an ICMP Echo Request to an IP that should be routed through 
a certain router (last hop before the host): 

[root@cart.mari] # ♦/icmpush -w -echo Target, 

-> Outgoing interface 192.168.1.5 

-> ICMP total size, - 12 byte a 

-> Outgoing interface « 192.16Q.1.5 

- > WjTtT ±± 1500 bytes 

Total packet size (ICMP + IP) = 32 bytes 
ICMP Echo Request packet sent to Taraet_lP (Target_IP) 

Receiving ICMP replies , . . 



Routers IP 

Type ■ Time Exceeded (OxB) 
Code ■ 0x0 Checksum «= 0xF9BF 

Id = 0X0 Seq# = 0X0 



. /icmpushs Program finished OK 



ICMP TTL:254 TOSsOxO ID: 13170 
ID:12291 Seq:317 ECHO 



Q2/13-09:16:31,724400 RoutersJCP -> 192.168.1.5 
ICMP TTL:57 TOS : 0x0 ID: 7410 



23 TTiere Is also a possibility ihat a filtering device te blocking our probes, or the repBes. 

2A The real IP's of the tarflOted host and Ins Router were replaced because of legal problems lhat might arise when the 
ISPs personal that was used would understand H was one of their Routers used for this experiment 
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TTL EXCEEDED 



00:13:12 prober > 192.160.2,5: icnrp: echo reply 
00:13:13 router> prober; icmp: hoafe unreachable 



Why Using ICMP Query Replies sometimes will be more beneficial than using ICMP Query 
Message types? 

We have more chance of getting through filtering devices, that will allow replies of certain ICMP 
Query message types to get back to the Issuing hosts, This might allow us to "penetrate" to 
deeper networks with our crafted reply. 

4,2 Inverse Mapping Using Other Protocols 

The technique of inverse mapping will work with other protocols as the stimulus. Ft will produce 
the same results since the destination Host (IP) will still be unreachable. The router one hop 
before the targeted host couid not arp the host, and win Issue an ICMP Host Unreachable 
regardless of the underlying protocol used. 



949 7609502 T-702 P 090/104 F- 

o 
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I — — — — 
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Diagram 1: The Inverse Mapping Idea 



4.3 Patterns we might see 

This type of scan will produce a numner of patterns. Not always, when we will see a router 
Issuing a hast unreachable It will be because some one mant to use the inverse mapping 
technique. 

Lets look at our first example: 

RouterIP > The_Same_IP : icnrp: host Host_A unreachable 
Router_IP > The_Same_IP t icnrp: host Hosfc_J) unreachable 
Router__IP > The_Same_IP : icmp: host Host_G unreachable 
* * » 

Router_JT.P > Tha_$ame_IP : icmp: host Host_N unreachable 

The same host is being used to scan an entire IP range of a targeted network. Some of the Hosts 
the malicious computer attacker tries to reach are not reachable. Still, the malicious computer 
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attacker gets an idea about what is not reachable. Sometimes these results are the only 
Indication that the malicious computer attacker will have about the presence of Hosts. 



Lets look at the next example; 

18?12:21. 901256 Roufcar_lF > 192.168.46.45: icmp: host x*x,x.l2 
unreachable 

18:12.33 .676136 Router_IP > 192.168.59,63; icmp: host x.x.x.12 
unreachable 

18:12:33.676218 Router_IP > 192.168.59,63: icmp: host X.X.X.12 
unreachable 

18;13:27. 084221 Roufcerjlp > 192.168.114.37: icmp: host x.x.x.12 
unreachable 

18:13:45.559706 Router_rF > 192.168.22.91: icmp: host x.x,x,12 
unreachable 

18:13:45.559856 Router_I5> > 192. 168. 22. 91: icmpr host x.x.x.12 
Unreachable 

16:13:48.413514 RouterJEP > 192 . 168 .250 .254 : icmp: host x.x.x.12 
unreachable 

18:13:48.413681 Router_IP > 192.168.250.254: icmp; host x.x,x*l2 
unreachable 

18:14:31.313495 Router_IP > 192 . 16B . 247 . 186 r icmp: host x.x.x.12 
unreachable 

18:14:31.313624 ROuterJIP > 192.168.247.186: icmp: host x.x.x.12 
unreachable 

18 :15s32. 884187 Router_IP > 192 . 16B . 12 . 213 ; Icmp; host X*X + X.12 
unreachable 



What we see here Is different Hosts (changed to 192.16B.xoc) failing to reach the x.xoM2 IP. The 
Router is sending them all an ICMP Host Unreachable error message. 

How come different Hosts (IPs) are seeking this host on such a short notice? 



Probably what we are seeing is a decoy scan- A decoy scan is a type of scan, which involves 
multiple IPs, which are fed to the network-scanning tool as decoys. The real IP of the malicious 
computer attacker (or a machine he compromised) will be among those. For the defending side a 
question will be asked: What IP among alt IPs, which are knocking on the door, Is the IP the 
attacker was using? 

With our example the IP is reported, to ail seeking hosts, to be unreachable. The Router Is trying 
to deliver the packet and fails with his ARP requests. 
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Diagram 2: A Decoy Scan Example 
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5.0 Using traceroute to Map a Network Topology 

Traceroute fs a Network debugging utility, which attempts to map all the hosts on a route to a 
certain destination host/machine. 

The program sands UDP (by default) or ICMP ECHO Request 25 datagrams in sets of three, to a 
certain destination host. The first three datagram's to be sent have a Tlme-to-Llve field value in 
the IP Header equals to one. The program lies on the fact that a router should decrement the TTL 
field value just before forwarding the datagram to another router/gateway. 

If a router discovers that the Time-To-Uve field value In an IP header of a datagram he process 
equals zero (or less) he would discard the datagram and generate an fCMF Time Exceeded 
Code 0 - transit TTL expired error message oack to the originating host 

This is when a successful round is completed and another set of three datagrams is sent, this 
time With a Tlme-to-LIve field value greater by one than the last set 

The originating host would know at which router the datagram expired since it receives this 
Information with the ICMP Time Exceeded in Transit error message (Source IP address of the 
ICMP error message would be the IP address of the router/gateway; inside the IP header + 64 
bits of original data of the datagram field we would have additional informaiton that would bound 
this ICMP error message to our Issued traceroute command). 




16 



31 



Typo 



Cote 



ChadraifTi 



Unused ( zero ) 



IDKjlvI- I £M Mtf - 'I -J.I 1- ■•/■ «- r _ I -J u -in 



Figure 10; ICMPTlmo Exceeded message format 



Since we increment the TTL field starting from one for each successful round (again - a round Is 
finished when the ICMP Time Exceeded in Transit error message Is received) until we receive an 
ICMP Port Unreachable error message (or ICMP ECHO Reply If we are using the ICMP ECHO 
request datagrams) from the destined machine, we map every router/gateway/host along the path 
to our destination. 

By default, when sending UDP packets we use a destination port which is probably hot used by 
the destination host so the UDP datagram would not be processes and an ICMP Port 
Unreachable error message would be generated from the destined machine. The destination port 
would be incremented with each probe sent 

We get ICMP responses provided there Is no prohibitive filtering or any packet loss. 



25 Microsoft WfrK*OW$ my and Microsoft Windows 2000 are using the tracert command* which use ICMP ECHO Request 
datagrams as fte default 
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The output wo see Is a Arte showing the Time-To-Live, the address of the gateway, and the round 
trip time of each probe. If we do not get a response back wjthfn 5 seconds an is printed, which 
represents no answer. 

A regular traceroute example with JCMP would be 28 : 



zuul:->traceimute -I lO.OfO.lo 

tracerouLa to 10.0.0.10 UD.O.Q.IO), 30 hopo max, 40 byto 
packets 

1 10. 0.0.1 (10.0,0.1) 0.540 ma 0,394 ma 0,397 ms 

2 10.0. 0.2 (10. 0.0.2) 2.4SS ms 2.479 ma ma 

3 10.0.0.3 (10.0.0.3) 4.812 RIB 4.780 ma 4.747 ma 

4 10.0.0.4 (10.0.0.4) 5.010 ms 4.903 mil 4. 980 ma 

5 10. Q. 0.5 (10. 0. 0.5) 5.520 ma 5.0D9 ms 6.061 ins 

6 10.0.0.6 (1O.0.O.6) 9.584 ma 21.754 idb 20.530 fnfl 

7 10.0. 0.7 (10.0.0.7) 69.685 ma 79.719 ms B5.91B .mO 
B 10,0.0,3 (10.0.0.9) 92.605 PS 80.361 ms 94.336 ms 

9 10.0.0.9 (10.0.0.9) 94.127 ma 81.764 ms 96.476 ms 

10 10.0.0.10 (10.0.0.10) 96.012 tftO 98.224 Iftfl 99.313 ms 



Lets assume that a network Is protected by a firewall, which blocks all incoming traffic except for 
traffic aimed at the DNS Machine's UDP port 53. If we would perform a regular traceroute aimed 
for the DNS machine's IP address, our UDP datagrams would be sent with a destination port, 
which Is probably not used on the targeted machine, and probably blocked by a Firewall or 
another filtering device. The traces would stop at the firewall at the entrance point ta the probed 
network. 



zuul i ->traceroute 10. 0.0,10 

tiracenrate to ia.0-O.lo (10,0.0.10), 30 bops max., 40 byte 
packets 

1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 rnfi 

2 1O.0.0.2 (10.0.0.2} 2.455 ma 2.479 ma 2.512 mS 

3 10.0.0.3 (10.0.0.3) 4.812 ms 4.780 ma 4.747 ma 

4 10.0.0.4 (10.0.0.4) 5.010 mfl 4.503 ms 4.980 ma 

5 10.0.0.5 (10.0.0.5) 5.520 ms 5.609 ms 6.061 ma 

6 10«D.D»6 (ID. 0,0. 6) 9.5B4 ms 21.754 ms 20.530 ma 

7 10.0.0.7 (10.0. 0.7) 89.889 ms 79.719 ms B5.91B mp 

8 10,0.0.8 (10.0.0.8) 92,505 mo 80.361 me 94.336 hjb 

9 * * * 

10 * * * 



We need to set the port number to 53 In onter to reach the DNS server. Since the traceroute 
program increases the port number every time it sends a UDP datagram, we need to calculate 
the port number to start with, so when a datagram would be processed by the Flrewair and 
would be examined, It would have the appropriate port and other Information needed to fit with 
the Access Control List. If we use a simple equation we can calculate the starting port 

(T arget port ~ (number of hops * number of probes)) -1 

The number of hops (gateways) from our probing machine to the firewall Is taken from our earlier 
traceroute. We use three probes for every query with the same TTL value, each onB of them uses 
a different destination port number. 



28 AH examples taken from "A Tracaroute-Uke Analysis of IP Packet Responses to Determine Gateway Access Control 
Lists" by David Goldsmith and Michael Shiftman. No real examples were provided because of legal Issues. 

27 A flrewal should not elicit any reply for any traffic destined directly for him. 
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suul ; ->traccroucc -p28 ia.o.0.10 

tvaeeroute to lO.O.O.io (io.O.D.10), 30 hops max, 40 byto packofca 



10.0.0.1 
10.0. 0.2 
10.0.0.3 



10,0, 
10.0, 
10.0. 
10.0, 
10,0, 



0.4 
0.5 
0.6 
0.7 

o.a 



9 10.0,0.9 

10 * 



(10.0.0,1) 0.501 ma 0,3*9 ma 0.335 ma 

(ID. 0,0. 2) 2.433 ma 2.940 ma 2,491 ma 

(10.0.0.3) 4.730 ma 4.330 ma 4.B85 ma 

(10.0.0.4) 5.136 ma 5.127 mo 4.733 mo 

(10.0.0,5) 5.650 mo 5.551 ma 6.1GB ma 

(10,0.0,6) 7.020 ms 20.554 ms 19.525 ma 

(10.0.0.7) 68.552 ms 9Q»0Q6 ma 93*447 ma 

(10. 0.0. 8) 93-009 mo 94.055 ms B8.122 mfl 

(10.0.0.9) 101.163 ma * * 



But with the regular traceroute program we now face another difficulty- After the datagram have 
passed the ACL of the Firewall (and wo assume the firewall lets ICMP TTL Exceeded messages 
out) and listed the outer leg of the Firewall Itself as the next hop* the next UDP datagram sent 
would be with a different port number - Than again It wouW be blocked by the firewall. 

A modification to the traceroute program has been made by Michael Shiffman 28 in order to stop 
the port incrementation. One side affect from sending Iraceroutes with a fixed port number, which 
IS allowed on the firewalls ACL, is the final datagram, which normally would generate an ICMP 
Port Unreachable message now would not be generated since the UDP port would be in a 
listening state on the probed machine and would not provide an answer. 



3CUUl:~>traceroutB -s -p53 10.0.0.15 v 
traceroute to ID. 0.0.15 (10. 0.0. IS), 30 hope max, 40*byto 
packets 

1 10.0.0.1 (10,0.0.1) 0.516 ms 0.396 ma 0.390 ma 

2 10.0.0.2 (10,0.0.2) 2.516 ms 2.476 ma 2.431 IRO 

3 10. o.o. 3 (10,0.0.3) 5.060 ma 4.848 ma 4.721 ma 

4 10. 0.0.4 (10.0.0.4} 5. Old ms 4.694 ma 4.973 mo 

5 1O.O.0.5 (10.0.0.5) 6.097 ma 5.856 THO 6.002 mo 

6 10,0.0.6 (10.0.0.6) 19.257 ma 9.002 me» 21.797 rtO 

7 10.0.0.7 (10.0.0.7) 84.753 mfl * * 

8 10.0.0.8 (10.0.O.B) 96.664 Art 99.006 ms 95.491 me 

9 10.0.0.9 (10.0.0.9) 94.300 ma * 56.549 ma 

10 10,Q.0.10 (10.0.0.10) 101.257 ma 107.154 mo 103.318 mfl 

11 10.0.0.11 (10. 0.0. 11) 102.847 mo 110.158 mo * 

12 10.0.0.12 (10. 0,0. 12) 192.196 ma 165.265 ma * 

13 10.0.0.13 (10.0.0.13) 160.151 ma 183,238 ma 183,458 raa 

14 10.0.0.14 (10.0.0.14) 216.972 no 209. 3QB mo 195. 6B6 mo 

15 10.0.0.15 (10.0,0,15) 236.102 mo 237.200 m» 230. 165 mo 



28 

http://www.pac{(atfarfoTv.p9t 
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6.0 The usage of ICMP in Active Operating System Fingerprinting Process 

Finger Printing Is thB art of Operating System Detection. 

A malicious computer attacker needs few pieces of information before lunching an attack. First, a 
target, a Most detected using a host detection method. The next piece of Information would be the 
services that are running on that host This would be done with one of the Port Scanning 
methods/The last piece of Information.would be the operating system used by the host. 

The Information would allow the malicious computer attacker to Identify rf the targeted host is 
vulnerable to a certain exploit aimed at a certain service version running on a certain operating 
system. 

In this section I have outlined the ICMP methods for this type of scan. Few methods are new and 
were discovered during this research. 

Using Regular ICMP Query. Messages 

6.1 The "Who answer what?" approach 

The question "Which operating system answer for what kind of ICMP Query messages?" help us 
identity certain groups of operating systems. 

For example, LINUX and *BSD based operating systems with default configuration answer for 
ICMP Echo requests and for ICMP Timestamp Requests. Until Microsoft Windows 2000 family of 
operating systems has been released It was a unique combination for these two groups of 
operating systems. Since the Microsoft Windows 2Q00 operating system family mimics the same 
behavior (yes mimic), it is no longer feasible to make this particular distinction. 

Microsoft might have been thinking that this way Of behavior might hide Microsoft windows 2000 
machines In the haze. As we will see with the examples given In this research paper they have 
much more to learn. 

The thing Is there is no clear distinction between one operating system to another based on this 
data. We can onlvgroup them together and try other methodologies In order to divide those 
groups a bit more . 

Other data we might use is "Which operating system answer for queries aimed at the broadcast / 
network address of the network they reside on?" 

For the complete mapping of the operating systems I have queried for this research please see 
"Appendix C: Mapping Operating Systems for answering/ discarding ICMP query message 
types' 1 , and "Appendix E: ICMP Query Message Types aimed at a Broadcast Address*, 

Two examples are given In this text for the usage of Operating System fingerprinting with the 
"Who answer what?" approach. 



o 



29 Note: irthe PMTTJ Discovery process using ICMP Echo requests Is enables with HP-UX 10.30 & 11.0* operating 
systems than our simple query wll trigger a -retaliation" from those machines, enabling us to Identify them very easily. For 
more Information on this Issue see section 6.2 
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6.1.2 Using ICMP Information Requests 

Because of the fact, that only few operating systems would reply to ICMP Information requests, 
we can group them together. 

From the Information given In table 2 in Section 2.5, we can conclude that HP-UX 10.20, AIX, 
ULTRIX & Open-VMS would be the only operating systems (among those I have tested) that 
would produce an ICMP Information reply for these queries. 

We can further distinguish between those operating systems If we would send an ICMP Address 
Mask Request and wait for the reply from the systems In question. AIX and HP-UX operating 
systems would not answer the query, while the ULTRIX & Open-VMS would. 



. ICMP Information Request 




ULTRIX OpenVMS Other OS^ 

AIX 



ICMP Address Mask Request . 




ULTRIX Open-VMS HP-UX 

AIX 



Diagram 3: Rnger Printing Using ICMP Information Request Combined with ICMP Address Mask Request 




6-1.3 Identifying Operating Systems according to their replies for non-ECHO ICMP 
requests aimed at the broadcast address 

If IP directed broadcasts are not blocked, than we can identify the answering machines quite 
easily. 

The first step is sending an ICMP Tlmestamp request aimed at the broadcast address of a 
targeted network. The operating systems who would answer would Include SUN Solaris, HP-UX 
10.20, and LINUX (Kernel version 2.2.x). We can further identify those operating systems by 
sending an ICMP Information request aimed at the broadcast address of the targeted network. 
HP-UX 10.20 would answer the query while SUN Solaris and UNUX wouW not To distinguish 
between those two we would send an ICMP Address Mask request to the IPs that did not answer 
in the previous step. SUN Solaris would reply to the query while LINUX machines based on 
Kernel 2.2.x would not 
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For complete Information see Section 2*6. 
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ICMP Tlmestamp Request aimed at the Broadcast 
Address of a Network 



Reply 




No Reply 



Solaris 
HP-UX 
LINUX Kernel 2.2.14 

ICMP Information Request aimed at the Broadcast 
Address of a Network 

0 



Reply 



Np Reply 



Other OS's 



HP-UX 



Solaris 
. LINUX Kernel 2.2.14 



ICMP Address Mask Request Aimed at Specific IPs 

© 

Raply / \ No Reply 



Solaris . 



LINUX Kernel U14 



Diagram 4: Finger Printing Using noi>ECHO ICMP Ouery Types aimed at the Broadcast Address of an 

Attacked Network 



6.2 The DF Bit Playground (Identifying Sun Solaris, HP-UX 10.30, 11.0x, and AIX 
4.3.x based machines) 

RFC 791 defines a three bits field used for various control flags In trie IP Header. 
Bit 0 is the reserved flag, and must be zero. 

Bit 1 , is called the Don't Fragment flag, and can have two values. A value of zero (not set) is 
equivalent to May Fragment, and a value of one Is equivalent to Don't Fragment If this flag is set 
than the fragmentation of this packet at the IP level Is not permitted, otherwise it Is. 
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Bit 2, Is called the More Fragments bit It can have two values. A value of zero fs equivalent to 
(this is the) Last Fragment, and a value of 1 is equivalent to More Fragments (are coming). 

The next field Ift the IP header Is the Fragment Offset field, which Identifies the fragment location 
relative to the beginning of the original ur>fragmented datagram (RFC 791, bottom of page 23). 

A close examination of the IGMP Query replies would reveal that some operating systems woufd 
set the DF bit with their replies. 

The tcpdump trace below illustrates the reply a Sun Solaris 2,7 box produced for an ICMP Echo 
Request: 



17:10:19.538020 if 4 > y.y.y.y > x.x.x.x : icmpr echo request (ttl 
255 , id 13170) 

4500 0024 3372 0000 ffoi 9602 yyyy yyyy 

xxxx xxxx 0BOO 54a4 Bd04 0000 cbe7 bc39 
8635 oaoo 

17:10*19. 905254 if 4 < x.x.x.x > y.y.y.y : icipp: echo reply (DF) (ttl 
333, id 24941) 

4500 0024 6ied 40OQ e901 3e07 xxxx xxxx 

yyyy yyyy oooo 5qa4 ad04 oooo cbe7 bc3 9 

B635 0800 



In the recent SING CVS (12 September 2000), written by Alfredo Andres OmeHa, which Is 
available from htto://sourcefome.net/orotects/slng t the option for detecting If the DF bit is set with 
an ICMP Query reply was added, after being request by me' The following is the same ICMP 
Echo request & reply, this time it is presented by SING: 



[rootflgodfather bin] # ./sing -echo Host_Address 
SINGing to www. openbsd.org <IP_Address) ; 16 data bytes 

16 bytes from IP^Addresa: icrap^seqcO DFJ ttl=>233 TOS»0 time-367 . 314 ms 

16 bytes from lP_Address: icmp^se^l DFi ttl«233 TOS»0 time=320, 020 me 

15 bytes from IP^Addreas : icmp^fieq;^ DF1 ttl=233 TOS-0 tiiue«370 . 037 ms 

16 bytes from lP_Address» icmp_seq=3 »f| ttl»233 TOS-0 time«330*02S me 

Host_Address sing statistics 

4 packets transmitted, 4 packets received, Ofc pacfcefc lose 
round- trip min/avg/raax ■■ 320*020/346.849/370.037 ms 



Since www.openbsd.ora uses a Sun Solaris operating system, this matches our findings. 

ICMP Query replies for an operating system maintains the same behavioral patterns, Either they 
set the DF bit on all ICMP query reply types or they do not 

Trie DF bit would be set by default with ICMP Query replies with Sun Solaris. With HP-UX 10.30, 
& 1 1 -Ox, and with AJX 4.3.x setting the DF Bit will vary from one queried host to another 
(explanation coming). It may be set with trie first ICMP Query reply onwards, or after a number of 
ICMP Query replies. This detail will help us to distinguish between Sun Solaris, HP-UX 10.30 & 
1 1 .Ox, and A1X 4.3 jc operating systems. 
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Why HP-UX 10.30 1 11.0 & AIX 4.3.x operating systems act this way? 

HP claims to have a proprietary method in order to determine the PMTU wrth HP-UX v10.30. and 
HP-UX v1 1 .Ox using iCMP Echo requests. AiX 4.3.x do exactly the same. 

The next trace Will help understanding the process taken by HPUX 10.30 & 1 1.0X and AIX 4.3a. 
Here I have sent an ICMP Echo request to an HP-UX 1 1 .0 machine: 

00:27:56.884147 pppO > y.y.y.y > x.x.K.x: icmp: ecbo request (ttl 255, 
id 13170) 3372 ooqo Jf01 7c51 yyyy VYT/ 

xxxx xxxx.OBOO 5238 6d04 0000 dce5 C339 
8b7d OdOO , , kl 

00 = 27=57.165620 pp P 0 < * > Y-Y-Y-Y i W echo reply (ttl 236, 

id 41996) ooQo ecQ1 lacl XX3C3C X300C 

yyyy yyyy oooo Sass 6d04 oooo dce5 c339 

Bb7d OdOO 

The first pair of ICMP Echo request and ICMP Echo reply was pr B tty usual.^ ^X m^hlne 
sent an ICMP Echo request and received ail ICMP Echo reply from the probed machine. One 
notable detail - the DF bit Is not set In the ICMP Echo reply. 

Than something that was not expectable has happened: 

00:27:57.435620 pppO < > Y-Y-Y-Y . e <*° l ™ } <Ctl 

j j 41 QR5) 

' 4500 05du a401 4000 ec01,d909 xxxjC ^odqC 

yyyy yyyy 0800 7e52 9abC defO 0000 0000 

oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo- 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo. oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo. 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo' oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 
oooo oooo oooo oooo oooo oooo oooo oooo 

47 

Copyright ® Oflr Arkln, 2000-2001 



PAGE 1 00/209 * RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPT0^ FXRF-2tt * DNIS:7469694 * CSID:9497609502 * DURATION (mm-ss):57-46 



Jun-30-2004 09:29pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 P. 101/104 F-609 



o ; n 

ICMP Usage In Scanning 
Version 2.5 



0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


□ 000 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


dooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo. 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oogo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


000D 


oooo 


oooo. 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000' 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo. 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo- 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 

46 


oooo 


oooo 


oooo 


oooo 



Copyright® QfirArWn. 2000-2001 
hHDVAwww.svs-security.com 



PAGE 101/209 * RCVD AT 7/1/2004 12:03:40 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/2 * DNIS:7469694 * CSID:9497609502 ' DURATION (mm-ss):5746 



Jun-30-2004 09:29pm From-KNOBBE MARTENS OLSON BEAR 



949 7609502 



T-702 ? 102/104 F- 



n o 

ICMP Uoege In Scorwlno 
Version 2.5 



0000 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


oooo 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


.0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


QOOO 


00.00 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


oooo 


oooo 


oooo 


oooo 


0000 


0000 


oooo 


oooo 


oooo 


oooo 







00:27:57.435672 pppO > y-Y-Y-V > X^X.X.UC: icmp: echo reply (ttl 255, id 
53) 
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The HPUX 1 1 x machine I have queried pinged mo bade! The (CMP Echo request size was 1600 
bytes. It was the maximum transfer unit my Internet Connection was allowed to process. The 
request was sent with the DF bit set Any router along the way, trying to fragment the request 
because the MTU of the destined network was smaller than the datagram's size would fail and 

send an ICMP Error message bade stating a fragmentation was required but the don't fragment 
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bit was set It would allow the sending machine to send a smaller steed datagram according tg its 
PMTU discovery process/algoiitnm with ICMP. if for this ICMP Echo request an ICMP Echo reply 
would be received, than the PMTU is discovered. 

00:27:57.885662 pppO > /• Y-Y-Y > x,x,x.x : icnip: echo request (ttl 255, 
id 13170) 

4500 0024 3372 oooo ff oi 7c5i yyyy yyyy 

aocxx xXXX 0800 5B32 6d04 0100 dde5 
8383 OdOO 

00:27:58 .155527 pppO < x.X-X,X > Y*Y*Y-Y icmp: echo reply (DF) (ttl 
236, id 41987) 

4500 0024 a4G3 4000 ecOl debf xxxx xjCU 

yyyy yyyy oo oo 6032 6do4 0100 ddes c339 

8383 OdOO 

The following ICMP Echo Request sent from my machine to the queried HP-UX 1 1 ,x Just 
milliseconds after my reply to the HP-UX"s query was sent It has resulted in an ICMP Echo reply 
coming back from the queried machine. This time the DF bit was set with the ICMP Echo reply, . 
Rather than sending an ICMP datagram that will be fragmented somewhere along the way to the 
destination machine, It is more beneficial from performance perspective, to fragment the ICMP 
datagram on sending. Setting the DF bit on the following replies would help to maintain the PMTU 
between the two systems, If for any reason, the PMTU would be decreased. For example, 
because the datagram have used another route to the destined system. 

Sending immediately another ICMP Query message type to this particular HP-UX 1 1 operating 
system based machine, will not result in the PMTU discovery process to be repeated. The DF Bit 
would be set within the ICMP Query reply. Expect a threshold to be maintained by the HP-UX 

I I jc. When reached the next time we query this host with any type of communication, the 
process of determining the PMTU using ICMP Echo request will begin again. 

Why this method is bound to failure? 

• Some ISPs would configure their routers not to allow fragmented ICMP datagrams 
through. I have encountered this behavior with different ISPs I have used. 

• Some machines would be configured not to reply for an ICMP Echo requests coming 
from the Internet (If you read all of this research paper you'll do that). 

• This abiliry can be used for a denial-service attack with the HP-UX 10.30, and/or 1 1 .Ox 
machines used as an amplifier for these attacks. Infect, HP has released a security 
bulletin dated February 13, 2000 about some issues regarding this PMTU discovery 
capability with ICMP. The bulletin, states that "Depending upon the amount and nature of 
the inbound traffic, an HP-UX 10.30/11.00/1 1.04 system can be used to flood a target 
system with IP packets which could result in a denial of service" 3 . 

• Easy Identification of HP-UX 1 0.30, 1 1 -Ox machines that had the default behavior not 
changed. 

This gives us the ability to distinguish between Sun Solaris machines, HP-UX 11. Ox/10.30 
machines, and AIX 4.3.x based machines. 

Sun Solaris sets the DF bit with the ICMP Query replies the operating system answers for, in 
order to support Its global PMTU discovery process. If the networking link will not let the ICMP 
Query reply to get back to the querying host, because the MTU used is higher than the allowed 



HP Security Bulletin - 'Security Vulnerability with PMTU strategy (revised)*, Febwary 1 3. 2000. 
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